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ABSTRACT 

DEPENDENT TYPES IN HASKELL: THEORY AND PRACTICE 
Richard A. Eisenberg 
Stephanie Weirich 


Haskell, as implemented in the Glasgow Haskell Compiler (GHC), has been adding 
new type-level programming features for some time. Many of these features—general¬ 
ized algebraic datatypes (GADTs), type families, kind polymorphism, and promoted 
datatypes—have brought Haskell to the doorstep of dependent types. Many depen- 
dently typed programs can even currently be encoded, but often the constructions are 
painful. 

In this dissertation, I describe Dependent Haskell, which supports full dependent 
types via a backward-compatible extension to today’s Haskell. An important contribu¬ 
tion of this work is an implementation, in GHC, of a portion of Dependent Haskell, 
with the rest to follow. The features I have implemented are already released, in 
GHC 8.0. This dissertation contains several practical examples of Dependent Haskell 
code, a full description of the differences between Dependent Haskell and today’s 
Haskell, a novel dependently typed lambda-calculus (called Pico) suitable for use as 
an intermediate language for compiling Dependent Haskell, and a type inference and 
elaboration algorithm, Bake, that translates Dependent Haskell to type-correct PlCO. 
Full proofs of type safety of PlCO and the soundness of Bake are included in the 
appendix. 
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Chapter 1 
Introduction 


Haskell has become a wonderful playground for type system experimentation. Despite 
its relative longevity—at roughly 25 years old [45]—type theorists still turn to Haskell 
as a place to build new type system ideas and see how they work in a practical 
setting [5, 11, 15, 16, 32, 40, 46, 49, 51, 53, 66, 75, 76]. As a result, Haskell’s type 
system has grown ever more expressive over the years. As the power of types in 
Haskell has increased, Haskellers have started to integrate dependent types into their 
programs [4, 30, 56, 60], despite the fact that today’s Haskell 1 does not internally 
support dependent types. Indeed, the desire to program in Haskell but with support 
for dependent types influenced the creation of Cayenne [3], Agda [68], and Idris [9]; 
all are Haskell-like languages with support for full dependent types. 

This dissertation closes the gap, by adding support for dependent types into Haskell. 
In this work, I detail both the changes to GHC’s internal language, previously known 
as System FC [87] but which I have renamed PlCO, and the changes to the surface 
language necessary to support dependent types. Naturally, I must also describe the 
elaboration from the surface language to the internal language, including type inference 
through my novel algorithm Bake. Along with the textual description contained 
in this dissertation, I have also partially implemented these ideas in GHC directly; 
indeed, my contributions were one of the key factors in making the current release of 
GHC a new major version. It is my expectation that I will implement the internal 
language and type inference algorithm described in this work in GHC in the near 
future. Much of my work builds upon the critical work of Gundry [37]; one of my chief 
contributions is adapting his work to work with the GHC implementation and further 
features of Haskell. 


1.1 Contributions 

I offer the following contributions: 

throughout this dissertation, a reference to “today’s Haskell” refers to the language implemented 
by the Glasgow Haskell Compiler (GHC), version 8.0, released in 2016. 
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Chapter 3 includes a series of examples of dependently typed programming in 
Haskell. Though a fine line is hard to draw, these examples are divided into two 
categories: programs where rich types give a programmer more compile-time 
checks of her algorithms, and programs where rich types allow a programmer to 
express a more intricate algorithm that may not be well typed under a simpler 
system. 

Although no new results are presented in Chapter 3, these examples are a true 
contribution of this dissertation. Dependently typed programs are still something 
of a rarity, as evidenced by the success at publishing novel dependently typed 
programs [8, 23, 61, 69]. This chapter extends our knowledge of dependently 
typed programming by showing how certain programs might look in Haskell. 
The two most elaborate examples are: 

- a dependently typed database access library based on the design of Oury 
and Swierstra [69] but with the ability to infer a database schema based 
on how its fields are used, and 

— a translation of Idris’s algebraic effects library [8] into Dependent Haskell 
that allows for an easy-to-use alternative to monad transformer stacks. 
With heavy use of singletons, it is possible to encode this library in today’s 
Haskell due to my implementation work. 

Section 3.3 then argues why dependent types in Haskell, in particular, are an 
interesting and worthwhile subject of study. 

Dependent Haskell (Chapter 4) is the surface language I have designed in this 
dissertation. This chapter is written to be useful to practitioners, being a user 
manual of sorts of the new features. In combination with Chapter 3, this chapter 
could serve to educate Haskellers on how to use the new features. 

In some ways, Dependent Haskell is similar to existing dependently typed 
languages, drawing no distinction between terms and types and allowing rich 
specifications in types. However, it differs in several key ways from existing 
approaches to dependent types: 

1. Dependent Haskell has the Type : Type axiom, avoiding the need for an 
infinite hierarchy of sorts [57, 80] used in other languages. (Section 4.4.1) 

2 . A key issue when writing dependently typed programs is in figuring out 
what information is needed at runtime. Dependent Haskell’s approach is to 
require the programmer to choose whether a quantified variable should be 
retained (making a proper n-type) or discarded (making a V-type) during 
compilation. 

3. In contrast to many dependently typed languages, Dependent Haskell is 
agnostic to the issue of termination. There is no termination checker in the 
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language, and termination is not a prerequisite of type safety. A drawback 
of this approach is that some proofs of type equivalence must be executed 
at runtime, as discussed in Section 4.4.5. 

4. As elaborated in Chapter 6, Dependent Haskell retains important type 
inference characteristics that exist in previous versions of Haskell (e.g., those 
characteristics described by Vytiniotis et al. [99]). In particular, all programs 
accepted by today’s GHC—including those without type signatures—are 
also valid in Dependent Haskell. 

• PlCO (pronounced “n-co”, never “peek-o”) is a new dependently typed A-calculus, 
intended as an internal language suitable as a target for compiling Dependent 
Haskell. (Chapter 5) PlCO allows full dependent types, has the Type : Type 
axiom, and yet has no computation in types. Instead of allowing type equality 
to include, say, /^-equivalence (as in Coq), type equality in PlCO is just in¬ 
equivalence. A richer notion of type equivalence is permitted through coercions, 
which witness the equivalence between two types. In this way, PlCO is a direct 
descendent of System FC [11, 32, 87, 105, 107] and of the evidence language of 
Gundry [37], 

PlCO supports unsaturated functions in types, while still allowing function 
application decomposition in its equivalence relation. 2 This is achieved by my 
novel separation of the function spaces of type constants, which are generative and 
injective, from the ordinary, unrestricted function space Allowing unsaturated 
functions in types is a key step forward PlCO makes over Gundry’s evidence 
language [37]; it means that all expressions can be promoted to types, in contrast 
to Gundry’s subset of terms shared with the language of types. 

In Appendix C, I prove the usual preservation and progress theorems for PlCO 
as well as a type erasure theorem that relates the operational semantics of PlCO 
to that of a simple A-calculus with datatypes and fix. In this way, I show that 
all the fancy types really can be erased at runtime. 

• The novel algorithm Bake (Chapter 6) performs type inference on the Depen¬ 
dent Haskell surface language, providing typing rules and an elaboration into 
PlCO. I am unaware of a similarly careful study of type inference in the context 
of dependent types. These typing rules contain an algorithmic specification of 
Dependent Haskell, detailing which programs should be accepted and which 
should be rejected. The type system is bidirectional and contains a novel treat¬ 
ment for inferring types around dependent pattern matches, among a few other, 
smaller innovations. I prove that the elaborated program is always well typed in 
Pico. 

• A partial implementation of the type system in this dissertation is available in 
GHC 8.0. Chapter 7 discusses implementation details, including the current state 

2 I am referring to the left and right coercions of System FC here. 
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of the implementation. It focuses on the released implementation of the system 
from Weirich et al. [105]. Considerations about implementing full Dependent 
Haskell are also included here. 

• Chapter 8 puts this work in context by comparing it to several other dependently 
typed systems, both theories and implementations. This chapter also suggests 
some future work that can build from the base I lay down here. 

Though not a new contribution, Chapter 2 contains a review of features available 
in today’s Haskell that support dependently typed programming. This is included 
as a primer to these features for readers less experienced in Haskell, and also as a 
counterpoint to the features discussed as parts of Dependent Haskell. 

This dissertation is most closely based upon my prior work with Weirich and 
Hsu [105]. That paper, focusing solely on the internal language, merges the type and 
kind languages but does not incorporate dependent types. I wrote the implementation 
of these ideas as a component of GHC 8, incorporating Peyton Jones’s extensive 
feedback. This dissertation work—particularly Chapter 6—also builds on a more 
recent paper with Weirich and Ahmed [33], which develops the theory around type 
inference where some arguments are visible (and must be supplied) and others are 
invisible (and may be omitted). Despite this background, almost the entirety of this 
dissertation is new work; none of my previous published work has dealt directly with 
dependent types. 

1.2 Implications beyond Haskell 

This dissertation necessarily focuses quite narrowly on discussing dependent types 
within the context of Haskell. What good is this work to someone uninterested in 
Haskell? I offer a few answers: 

• In my experience, many people both in the academic community and beyond 
believe that a dependently typed language must be total in order to be type-safe. 
Though Dependent Haskell is not the first counterexample to this mistaken 
notion (e.g., [3, 12]), the existence of this type-safe, dependently typed, non-total 
language may help to dispel this myth. 

• This is the first work, to my knowledge, to address type inference with let- 
generalization (of top-level constructs only, see Section 6.2.2) and dependent 
types. With the caveat that non-top-level let declarations are not generalized, 
I claim that the Bake algorithm I present in Chapter 6 is conservative over 
today’s Haskell and thus over Hindley-Milner. See Section 6.8.2. 

• Even disregarding let-generalization, Bake is the first (to my knowledge) thor¬ 
ough treatment of type inference for dependent types. My bidirectional type 
inference algorithm infers whether or not a pattern match should be treated 
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as a dependent or a traditional match, a feature that could be ported to other 
languages. 

• Once Dependent Haskell becomes available, I believe dependent types will become 
popular within the Haskell community, given the strong encouragement I have 
received from the community and the popularity of my singletons library [29, 30]. 
Perhaps this popularity will inspire other languages to consider adding dependent 
types, amplifying the impact of this work. 


As the features in this dissertation continue to become available, I look forward to 
seeing how the Haskell community builds on top of my work and discovers more and 
more applications of dependent types. 
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Chapter 2 
Preliminaries 


This chapter is a primer for type-level programming facilities that exist in today’s 
Haskell. It serves both as a way for readers less experienced in Haskell to understand 
the remainder of the dissertation and as a point of comparison against the Dependent 
Haskell language I describe in Chapter 4. Those more experienced with Haskell may 
easily skip this chapter. However, all readers may wish to consult Appendix A to learn 
the typographical conventions used throughout this dissertation. 

I assume that the reader is comfortable with a typed functional programming 
language, such as Haskell98 or a variant of ML. 

2.1 Type classes and dictionaries 

Haskell supports type classes [102], An example is worth a thousand words: 

class Show a where 
show :: a —> String 
instance Show Bool where 
show True = "True" 
show False = "False" 

This declares the class Show , parameterized over a type variable a, with one method 
show. The class is then instantiated at the type Bool , with a custom implementation 
of show for Bools. Note that, in the Show Bool instance, the show function can use 
the fact that a is now Bool: the one argument to show can be pattern-matched against 
True and False. This is in stark contrast to the usual parametric polymorphism of a 
function show':: a —> String , where the body of show' cannot assume any particular 
instantiation for a. 

With Show declared, we can now use this as a constraint on types. For example: 

smooshList:: Show a =>• [a] —>• String 
smooshList xs = concat (map show xs ) 
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The type of smooshList says that it can be called at any type a, as long as there 
exists an instance Show a. The body of smooshList can then make use of the Show a 
constraint by calling the show method. If we leave out the Show a constraint, then the 
call to show does not type-check. This is a direct result of the fact that the full type 
of show is really Show a => a —> String. (The Show a constraint on show is implicit, 
as the method is declared within the Show class declaration.) Thus, we need to know 
that the instance Show a exists before calling show at type a. 

Operationally, type classes work by passing dictionaries [39]. A type class dictionary 
is simply a record containing all of the methods defined in the type class. It is as if we 
had these definitions: 

data ShowDict a = MkShowDict {showMethod :: a —>■ String} 

showBool :: Bool —>• String 

showBool True = "True" 

showBool False = "False" 

showDictBool:: ShowDict Bool 

showDictBool = MkShowDict showBool 

Then, whenever a constraint Show Bool must be satisfied, GHC produces the dictionary 
for showDictBool. This dictionary actually becomes a runtime argument to functions 
with a Show constraint. Thus, in a running program, the smooshList function actually 
takes two arguments: the dictionary corresponding to Show a and the list [a]. 

2.2 Families 

2.2.1 Type families 

A type family [15, 16, 32] is simply a function on types. (I sometimes use “type function” 
and “type family” interchangeably.) Here is an uninteresting example: 

type family F i a where 

Fi Int = Bool 
Fi Char = Double 
useF 1 :: F 1 Int —>• F l Char 
useF i True =1.0 
useF i False = (-1.0) 

We see that GHC simplifies Fi Int to Bool and F { Char to Double in order to type-check 
useF i. 

F i is a closed type family, in that all of its defining equations are given in one 
place. This most closely corresponds to what functional programmers expect from 
their functions. Today’s Haskell also supports open type families, where the set of 
defining equations can be extended arbitrarily. Open type families interact particularly 
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well with Haskell’s type classes, which can also be extended arbitrarily. Here is a more 
interesting example than the one above: 

type family Element c 
class Collection c where 
singleton :: Element c —>• c 
type instance Element [a] = a 
instance Collection [a] where 
singleton x = [x] 

type instance Element (Set a) = a 
instance Collection (Set a) where 
singleton = Set.singleton 

Because the type family Element is open, it can be extended whenever a programmer 
creates a new collection type. 

Often, open type families are extended in close correspondence with a type class, 
as we see here. For this reason, GHC supports associated open type families, using 
this syntax: 

class Collection' c where 
type Element' c 
singleton’:: Element' c —>• c 
instance Collection' [a] where 
type Element' [a] = a 
singleton' x = [x] 

instance Collection' (Set a) where 
type Element' (Set a) = a 
singleton' = Set.singleton 

Associated type families are essentially syntactic sugar for regular open type families. 

Partiality in type families A type family may optionally be partial , in that it is 
not defined over all possible inputs. This poses no problems in the theory or practice 
of type families. If a type family is used at a type for which it is not defined, the type 
family application is considered to be stuck. For example: 

type family F 2 a 

type instance F 2 Int = Bool 

Suppose there are no further instances of F 2 . Then, the type F 2 Char is stuck. It does 
not evaluate, and is equal only to itself. 

It is impossible for a Haskell program to detect whether or not a type is stuck, as 
doing so would require pattern-matching on a type family application—this is not 




possible. This is a good design because a stuck open type family might become unstuck 
with the inclusion of more modules, defining more type family instances. Stuckness is 
therefore fragile and may depend on what modules are in scope; it would be disastrous 
if a type family could branch on whether or not a type is stuck. 

2.2.2 Data families 

A data family defines a family of datatypes. An example shows best how this works: 

data family Array a — compact storage of elements of type a 
data instance Array Bool = MkArrayBool Byte Array 
data instance Array Int = MkArraylnt (Vector Int) 

With such a definition, we can have a different runtime representation for Array Bool 
than we do for Array Int, something not possible with more traditional parameterized 
types. 

Data families do not play a large role in this dissertation. 


2.3 Rich kinds 

2.3.1 Kinds in Haskell98 

With type families, we can write type-level programs. But are our type-level programs 
correct? We can gain confidence in the correctness of the type-level programs by 
ensuring that they are well-kinded. Indeed, GHC does this already. For example, if we 
try to say Element Maybe, we get a type error saying that the argument to Element 
should have kind *, but Maybe has kind *—>•*. 

Kinds in Haskell are not a new invention; they are precisely defined in the Haskell98 
report [71]. Because type constructors in Haskell may appear without their arguments, 
Haskell needs a kinding system to keep all the types in line. For example, consider the 
library definition of Maybe: 

data Maybe a = Nothing \ Just a 

The word Maybe, all by itself, does not really represent a type. Maybe Int and 
Maybe Bool are types, but Maybe is not. The type-level constant Maybe needs to be 
given a type to become a type. The kind-level constant * contains proper types, like 
Int and Bool. Thus, Maybe has kind * —>• *. 

Accordingly, Haskell’s kind system accepts Maybe Int and Element [Bool], but 
rejects Maybe Maybe and Bool Int as ill-kinded. 



2.3.2 Promoted datatypes 

The kind system in Haskell98 is rather limited. It is generated by the grammar 
k :: = * | k —>• k, and that’s it. When we start writing interesting type-level programs, 
this almost-unityped limitation bites. 

For example, previous to recent innovations, Haskellers wishing to work with 
natural numbers in types would use these declarations: 

data Zero 
data Succ a 

We can now discuss Succ ( Succ Zero ) in a type and treat it as the number 2. However, 
we could also write nonsense such as Succ Bool and Maybe Zero. These errors do not 
imperil type safety, but it is natural for a programmer who values strong typing to 
also pine for strong kinding. 

Accordingly, Yorgey et al. [107] introduce promoted datatypes. The central idea 
behind promoted datatypes is that when we say 

data Bool = False \ True 

we declare two entities: a type Bool inhabited by terms False and True ; and a kind 
Bool inhabited by types ’ False and ’ True . 3 We can then use the promoted datatypes 
for more richly kinded type-level programming. 

A nice, simple example is type-level addition over promoted unary natural numbers: 

data Nat = Zero \ Succ Nat 
type family a + b where 

’Zero + b = b 
’Succ a + b = ’Succ (a + b) 

Now, we can say ’ Succ ’ Zero + ’ Succ (’Succ ’Zero) and GHC will simplify the type to 
’Succ (’Succ (’Succ ’Zero)). We can also see here that GHC does kind inference on 
the definition for the type-level +. We could also specify the kinds ourselves like this: 

type family (a :: Nat) + (b :: Nat ) :: Nat where ... 

Yorgey et al. [107] detail certain restrictions in what datatypes can be promoted. 
A chief contribution of this dissertation is lifting these restrictions. 

2.3.3 Kind polymorphism 

A separate contribution of the work of Yorgey et al. [107] is to enable kind polymorphism. 
Kind polymorphism is nothing more than allowing kind variables to be held abstract, 

3 The new kind does not get a tick ’ but the new types do. This is to disambiguate a promoted data 
constructor ’X from a declared type X; Haskell maintains separate type and term namespaces. The 
ticks are optional if there is no ambiguity, but I will always use them throughout this dissertation. 
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just like functional programmers frequently do with type variables. For example, here 
is a type function that calculates the length of a type-level list at any kind: 


type family Length ( list:: [k]) :: Nat where 
Length ’[] = ’Zero 

Length (x’:xs) = 'Succ (Length xs) 

Kind polymorphism extends naturally to constructs other than type functions. 
Consider this datatype: 

data T f a = MkT (f a) 

With the PolyKinds extension enabled, GHC will infer a most-general kind V /r. (/c —>• 
*) —>• k —>• * for T. In Haskell98, on the other hand, this type would have kind 
(*—>•*) —>•*—>•*, which is less general. 

A kind-polymorphic type has extra, invisible parameters that correspond to kind 
arguments. When I say invisible here, I mean that the arguments do not appear 
in Haskell source code. With the -fprint-explicit-kinds flag, GHC will print 
kind parameters when they occur. Thus, if a Haskell program contains the type 
T Maybe Bool and GHC needs to print this type with -fprint-explicit-kinds, 
it will print T * Maybe Bool , making the * kind parameter visible. Today’s Haskell 
makes an inflexible choice that kind arguments are always invisible, which is relaxed in 
Dependent Haskell. See Section 4.2.3 for more information on visibility in Dependent 
Haskell. 


2.3.4 Constraint kinds 

Bolingbroke introduced constraint kinds to GHC. 4 Haskell allows constraints to be 
given on types. For example, the type Show a =>• a —>■ String classifies a function that 
takes one argument, of type a. The Show a =>• constraint means that a is required to 
be a member of the Show type class. Constraint kinds make constraints fully first-class. 
We can now write the kind of Show as * — y Constraint. That is, Show Int (for example) 
is of kind Constraint. Constraint is a first-class kind, and can be quantified over. A 
useful construct over Constraints is the Some type: 

data Some ::(*—)■ Constraint ) —>• * where 
Some :: c a => a Some c 

If we have a value of Some Show, stored inside it must be a term of some (existentially 
quantified) type a such that Show a. When we pattern-match against the constructor 
Some, we can use this Show a constraint. Accordingly, the following function type- 
checks (where show :: Show a => a —> String is a standard library function): 

4 http://blog.omega-prime.co.uk/?p=127 
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showSomething :: Some Show —>• String 
showSomething (Some thing ) = show thing 

Note that there is no Show a constraint in the function signature—we get the constraint 
from pattern-matching on Some, instead. 

The type Some is useful if, say, we want a heterogeneous list such that every 
element of the list satisfies some constraint. That is, each element of [Some Show] can 
be a different type a, as long as Show a holds: 

heteroList :: [Some Show] 

heteroList = [Some True, Some (5 :: lnt),Some (Just ())] 
print List :: [Some Show] —> String 

print List things = " [" -H- intercalate ", " (map showSomething things ) -H- "]" 


A> putStrLn $ printList heteroList 
[ True, 5, Just ()] 


2.4 Generalized algebraic datatypes 

Generalized algebraic datatypes (or GADTs) are a powerful feature that allows term- 
level pattern matches to refine information about types. They undergird much of the 
programming we will see in the examples in Chapter 3, and so I defer most of the 
discussion of GADTs to that chapter. 

Here, I introduce one particularly important GADT: propositional equality. The 
following definition appears now as part of the standard library shipped with GHC, in 
the Data. Type.Equality module: 

data (a :: k) :~: (b :: k ) where 
Refl:: a :~: a 

The idea here is that a value of type r :~: cr (for some r and o) represents evidence 
that the type r is in fact equal to the type cr. Here is a use of this type, also from 
Data.Type.Equality: 

castWith :: (a :~: b) —>■ a —>• b 
castWith Refl x = x 

Here, the castWith function takes a term of type a:~: b —evidence that a equals b —and 
a term of type a. It can immediately return this term, x, because GHC knows that a 
and b are the same type. Thus, x also has type b and the function is well typed. 

Note that castWith must pattern-match against Refl. The reason this is necessary 
becomes more apparent if we look at an alternate, entirely equivalent way of defining 
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data (a :: k) (b :: k) where 

Ret /:: (a ~ b) => a:~: b 


In this variant, I define the type using the Haskell98-style syntax for datatypes. This 
says that the Ref! constructor takes no arguments, but does require the constraint that 
a ~ b. The constraint (~) is GHC’s notation for a proper type equality constraint. 
Accordingly, to use Reft at a type r cr, GHC must know that t ~ a —in other 
words, that t and cr are the same type. When Ref I is matched against, this constraint 
t ~ cr becomes available for use in the body of the pattern match. 

Returning to castWith , pattern-matching against Reft brings a ~ b into the 
context, and GHC can apply this equality in the right-hand side of the equation to 
say that x has type b. 

Operationally, the pattern-match against Ref I is also important. This match is what 
forces the equality evidence to be reduced to a value. As Haskell is a lazy language, it is 
possible to pass around equality evidence that is _L. Matching evaluates the argument, 
making sure that the evidence is real. The fact that type equality evidence must exist 
and be executed at runtime is somewhat unfortunate. See Section 3.3.3 and Section 
4.4.5 for some discussion. 


2.5 Higher-rank types 

Standard ML and Haskell98 both use, essentially, the Hindley-Milner (HM) type 
system [20, 43, 63]. The HM type system allows only prenex quantification , where a 
type can quantify over type variables only at the very top. The system is based on 
types , which have no quantification, and type schemes , which do: 

r ::= a \ H \ t % t 2 types 

cr :: = Vce.cr | r type schemes 

Here, I use a to stand for any of a countably infinite set of type variables and H to 
stand for any type constant (including (—>■)). 

Let-bound definitions in HM are assigned type schemes; lambda-bound definitions 
are assigned monomorphic types, only. Thus, in HM, it is appropriate to have a function 
length :: V a. [a] — > Int but disallowed to have one like bad w {d a. a —t a —t a) —t Int: 
bad's type has a V somewhere other than at the top of the type. This type is of the 
second rank, and is forbidden in HM. 

On the other hand, today’s GHC allows types of arbitrary rank. Though a full 
example of the usefulness of this ability would take us too far afield, Lammel and 
Peyton Jones [53] and Washburn and Weirich [103] (among others) make critical use 
of this ability. The cost, however, is that higher-rank types cannot be inferred. For 
this reason, this definition of higherRank 

higherRank f = (f True, f ’x’) 


13 




will not compile without a type signature. Without the signature, GHC tries to unify 
the types Char and Bool, failing. However, providing a signature 

higherRank :: (V a. a 4 a) 4 (Bool, Char ) 
does the trick nicely. 

Type inference in the presence of higher-rank types is well studied, and can be 
made practical via bidirectional type-checking [24, 74], 


2.6 Scoped type variables 

A modest, but subtle, extension in GHC is ScopedTypeVariables, which allows a 
programmer to refer back to a declared type variable from within the body of a 
function. As dealing with scoped type variables can be a point of confusion for Haskell 
type-level programmers, I include a discussion of it here. 

Consider this implementation of the left fold fold I: 

foldl :: (b — y a — y b) —y b — y [a] —>• b 
foldl f zO xsO = Igo zO xsO 

where 

lgoz[] =z 

Igo z (x : xs ) = Igo (f z x) xs 

It can be a little hard to see what is going on here, so it would be helpful to add a 
type signature to the function Igo , thus: 

Igo :: 6 —^ [a] —^ 6 

Yet, doing so leads to type errors. The root cause is that the a and b in Igo' s type 
signature are considered independent from the a and b in foldl' s type signature. It 
is as if we’ve assigned the type bO —y [aO] —y bO to Igo. Note that Igo uses f in its 
definition. This f is a parameter to the outer foldl , and it has type b —y a —y b. When 
we call f z x in Igo, we’re passing z :: bO and x :: [aO] to f, and type errors ensue. 

To make the a and b in foldl' s signature be lexically scoped, we simply need to 
quantify them explicitly. Thus, the following gets accepted: 

foldl :: V a b. (b — y a — y 6) — y b — y [a] — y b 
foldl f zO xsO = Igo zO xsO 

where 

Igo :: b-y [a] -y b 

lgoz[] =z 

Igo z (x : xs) = Igo (f z x) xs 

Another particular tricky point around ScopedTypeVariables is that GHC will not 
warn you if you are missing this extension. 
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2.7 Functional dependencies 

Although this dissertation does not dwell much on functional dependencies, I include 
them here for completeness. 

Functional dependencies are GHC’s earliest feature introduced to enable rich type- 
level programming [49, 88]. They are, in many ways, a competitor to type families. 
With functional dependencies, we can declare that the choice of one parameter to a 
type class fixes the choice of another parameter. For example: 

class Pred (a :: Nat ) (b :: Nat ) | a —» b 
instance Pred ’Zero ’Zero 

instance Pred (’Succ n) n 

In the declaration for class Pred (“predecessor”), we say that the first parameter, a, 
determines the second one, b. In other words, b has a functional dependency on a. 
The two instance declarations respect the functional dependency, because there are 
no two instances where the same choice for a but differing choices for b are made. 

Functional dependencies are, in some ways, more powerful than type families. For 
example, consider this definition of Plus: 

class Plus (a :: Nat ) (b :: Nat ) (r :: Nat ) \ a b r, r a —> b 
instance Plus ’Zero b b 

instance Plus a b r =>- Plus (’Succ a) b (’Succ r) 

The functional dependencies for Plus are more expressive than what we can do for 
type families. (However, see the work of Stolarek et al. [86], which attempts to close 
this gap.) They say that a and b determine r, just like the arguments to a type family 
determine the result, but also that r and a determine b. Using this second declared 
functional dependency, if we know Plus a b r and Plus a b’ r, we can conclude b = b’. 
Although the functional dependency r b —>• a also holds, GHC is unable to prove this 
and thus we cannot declare it. 

Functional dependencies have enjoyed a rich history of aiding type-level pro¬ 
gramming [52, 59, 70]. Yet, they require a different paradigm to much of functional 
programming. When writing term-level definitions, functional programmers think in 
terms of functions that take a set of arguments and produce a result. Functional 
dependencies, however, encode type-level programming through relations, not proper 
functions. Though both functional dependencies and type families have their place in 
the Haskell ecosystem, I have followed the path taken by other dependently typed 
languages and use type-level functions as the main building blocks of Dependent 
Haskell, as opposed to functional dependencies. 


15 




Chapter 3 
Motivation 


Functional programmers use dependent types in two primary ways, broadly speaking: 
in order to prevent erroneous programs from being accepted, and in order to write 
programs that a simply typed language cannot accept. In this chapter, I will motivate 
the use of dependent types from both of these angles. The chapter concludes with a 
section motivating why Haskell, in particular, is ripe for dependent types. 

As a check for accuracy in these examples and examples throughout this dissertation, 
all the indented, typeset code is type-checked against my implementation every time 
the text is typeset. 

The code snippets throughout this dissertation are presented on a variety of 
background colors. A white background indicates code that works in GHC 7.10 and 
(perhaps) earlier. A light green background highlights code that newly works in 
GHC 8.0 due to my implementations of previously published papers [33, 105]. A 
light yellow background indicates code that does not work verbatim in GHC 8.0, but 
could still be implemented via the use of singletons [30] and similar workarounds. A 
light red background marks code that does not currently work in due to bugs. To my 
knowledge, there is nothing more than engineering (and perhaps the use of singletons) 
to get these examples working. 

Beyond the examples presented here, the literature is accumulating a wide variety of 
examples of dependently typed programming. Particularly applicable are the examples 
in Oury and Swierstra [69], Lindley and McBride [56], and Gundry [37, Chapter 8]. 

3.1 Eliminating erroneous programs 

3.1.1 Simple example: Length-indexed vectors 

We start by examining length-indexed vectors. This well-worn example is still useful, as 
it is easy to understand and still can show off many of the new features of Dependent 
Haskell. 
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3.1.1.1 Vec definition 

Here is the definition of a length-indexed vector: 

data Nat = Zero \ Succ Nat — first, some natural numbers 
data Vec :: Type — y Nat —y Type where 
Nil :: Vec a ’ Zero 

(:>) :: a —y Vec a n —y \/ec a (’ Succ n ) 

infixr 5 :> 


I will use ordinary numerals as elements of Nat in this text. 5 The Vec type is parame¬ 
terized by both the type of the vector elements and the length of the vector. Thus 
True :> Nil has type Vec Bool 1 and ’x’ :> ’y’ :> ’z’ :> Nil has type Vec Char 3. 

While Vec is a fairly ordinary GADT, we already see one feature newly introduced 
by my work: the use of Type in place of *. Using * to classify ordinary types is 
troublesome because * can also be a binary operator. For example, should F * Int be 
a function F applied to * and Int or the function * applied to F and /nt? In order to 
avoid getting caught on this detail, Dependent Haskell introduces Type to classify 
ordinary types. (Section 7.4 discusses a migration strategy from legacy Haskell code 
that uses *.) 

Another question that may come up right away is about my decision to use Nats 
in the index. Why not Integers ? In Dependent Haskell, Integers are indeed available 
in types. However, since we lack simple definitions for Integer operations (for example, 
what is the body of Integer's + operation?), it is hard to reason about them in types. 
This point is addressed more fully in Section 7.5. For now, it is best to stick to the 
simpler Nat type. 

3.1.1.2 append 

Let’s first write an operation that appends two vectors. We already need to think 
carefully about types, because the types include information about the vectors’ lengths. 
In this case, if we combine a Vec a n and a Vec a m, we had surely better get a 
Vec a (n + m). Because we are working over our Nat type, we must first define addition: 

(-)-) :: Nat — y Nat —^ Nat 

Zero + m = m 

Succ n + m = Succ (n + m ) 

Now that we have worked out the hard bit in the type, appending the vectors 
themselves is easy: 


5 In contrast, numerals used in types in GHC are elements of a built-in type Nat that uses a more 
efficient binary representation. It cannot be pattern-matched against. 
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append :: Vec a n -> Vec a m —>• Vec a (n ’+ m) 

append Nil w — w 

append (a :> v) w = a :> (append v w) 


There is a curiosity in the type of append: the addition between n and m is performed 
by the operation ’+. Yet we have defined the addition operation +. What’s going on 
here? 

Haskell maintains two separate namespaces: one for types and one for terms. Doing 
so allows declarations like data X = X, where the data constructor X has type X. 
With Dependent Haskell, however, terms may appear in types. (And types may, less 
frequently, appear in terms; see Section 3.1.3.2.) We thus need a mechanism for telling 
the compiler which namespace we want. In a construct that is syntactically a type 
(that is, appearing after a :: marker or in some other grammatical location that is 
“obviously” a type), the default namespace is the type namespace. If a user wishes 
to use a term-level definition, the term-level definition is prefixed with a ’. Thus, 
’+ simply uses the term-level + in a type. Note that the ’ mark has no semantic 
content—it is not a promotion operator. It is simply a marker in the source code to 
denote that the following identifier lives in the term-level namespace. 

The fact that Dependent Haskell allows us to use our old, trusty, term-level + in a 
type is one of the two chief qualities that makes it a dependently typed language. 

3.1.1.3 replicate 

Let’s now write a function that can create a vector of a given length with all elements 
equal. Before looking at the function over vectors, we’ll start by considering a version 
of this function over lists: 

listReplicate :: Nat —> a —»■ [a] 

listReplicate Zero _ = [] 

listReplicate (Succ n) x = x : listReplicate n x 

With vectors, what will the return type be? It surely will mention the element 
type a, but it also has to mention the desired length of the list. This means that 
we must give a name to the Nat passed in. Here is how it is written in Dependent 
Haskell: 

replicate :: V a. n (n :: Nat ) —>• a —> Vec a n 

replicate Zero _ = Nil 

replicate (Succ n) x = x :> replicate n x 


The first argument to replicate is bound by n (n:: Nat). Such an argument is available 
for pattern matching at runtime but is also available in the type. We see the value n 
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used in the result Vec a n. This is an example of a dependent pattern match, and how 
this function is well-typed is considered is some depth in Section 4.3.3. 

The ability to have an argument available for runtime pattern matching and 
compile-time type checking is the other chief quality that makes Dependent Haskell 
dependently typed. 

3.1.1.4 Invisibility in replicate 

The first parameter to replicate above is actually redundant, as it can be inferred from 
the result type. We can thus write a version with this type: 

replicatelnvis :: n (n :: Nat). V a. a —>• Vec a n 


Note that the type begins with n (n :: Nat), instead of n (n :: Nat) —h The use of the 
. there recalls the existing Haskell syntax of V a. , which denotes an invisible argument 
a. Invisible arguments are omitted at function calls and definitions. On the other hand, 
the ^ in n (n :: Nat) —> means that the argument is visible and must be provided 
at every function invocation and defining equation. This choice of syntax is due to 
Gundry [37]. Some readers may prefer the terms explicit and implicit to describe 
visibility; however, these terms are sometimes used in the literature (e.g., [64]) when 
talking about erasure properties. I will stick to visible and invisible throughout this 
dissertation. 

We can now use type inference to work out the value of n that should be used: 

fourTrues :: Vec Bool 4 
fourTrues = replicatelnvis True 

How should we implement replicatelnvis, however? We need to use an invisibility 
override. The implementation looks like this: 

replicatelnvis @Zero = Nil 
replicatelnvis @(Succ ) x = x :> replicatelnvis x 


The @ in those patterns means that we are writing an ordinarily invisible argument 
visibly. This is necessary in the body of replicatelnvis as we need to pattern match on the 
choice of n. An invisibility override can also be used at call sites: replicatelnvis @2 ’q’ 
produces the vector ’q’ :> ’q’ :> Nil of type Vec Char 2. It is useful when we do not 
know the result type of a call to replicatelnvis. 6 

6 The use of @ here is a generalization of its use in GHC 8 in visible type application [33]. 
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3.1.1.5 Computing the length of a vector 

Given a vector, we would like to be able to compute its length. At first, such an idea 
might seem trivial—the length is right there in the type! However, we must be careful 
here. While the length is indeed in the type, types are erased in Haskell. That length 
is thus not automatically available at runtime for computation. We have two choices 
for our implementation of length: 

lengthRel :: H n.Va. Vec a n —>• Nat 
length Re I @n _ = n 

lengthlrrel :: V n a. Vec a n —>• Nat 

lengthlrrel Nil = 0 

lengthlrrel ( „ :> v) — 1 — lengthlrrel v 

The difference between these two functions is whether or not they quantify n relevantly. 
A relevant parameter, bound by n, is one available at runtime. 7 In length Re I, the 
type declares that the value of n, the length of the Vec a n is available at runtime. 
Accordingly, lengthRel can simply return this value. The one visible parameter, of type 
Vec a n is needed only so that type inference can infer the value of n. This value must 
be somehow known at runtime in the calling context, possibly because it is statically 
known (as in lengthRel fourTrues ) or because n is available relevantly in the calling 
function. 

On the other hand, lengthlrrel does not need runtime access to n; the length is 
computed by walking down the vector and counting the elements. When lengthRel is 
available to be called, both lengthRel and lengthlrrel should always return the same 
value. (In contrast, lengthlrrel is always available to be called.) 

The choice of relevant vs. irrelevant parameter is denoted by the use of n or V in 
the type: lengthRel says n n while lengthlrrel says V n. The programmer must choose 
between relevant and irrelevant quantification when writing or calling functions. (See 
Section 8.7 for a discussion of how this choice relates to decisions in other dependently 
typed languages.) 

We see also that lengthRel takes n before a. Both are invisible, but the order is 
important because we wish to bind the first one in the body of lengthRel. If I had 
written lengthRel’ s type beginning with V a. n n. , then the body would have to be 
lengthRel @n _ = n. 

3.1.1.6 Conclusion 

These examples have warmed us up to examine more complex uses of dependent types 
in Haskell. We have seen the importance of discerning the relevance of a parameter, 
invisibility overrides, and dependent pattern matching. 

7 This is a slight simplification, as relevance still has meaning in types that are erased. See Section 
4.2.2. 
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3.1.2 A strongly typed simply typed A-calculus interpreter 

It is straightforward to write an interpreter for the simply typed A-calculus (STLC) 
in Haskell. However, how can we be sure that our interpreter is written correctly? 
Using some features of dependent types—notably, generalized algebraic datatypes, or 
GADTs—we can incorporate the STLC’s type discipline into our interpreter. 8 Using 
the extra features in Dependent Haskell, we can then write both a big-step semantics 
and a small-step semantics and have GHC check that they correspond. 

3.1.2.1 Type definitions 

Our first step is to write a type to represent the types in our A-calculus: 

data Ty = Unit \ Ty 7y 

infixr 0 

I choose Unit as our one and only base type, for simplicity. This calculus is clearly 
not suitable for computation, but it demonstrates the use of GADTs well. The model 
described here scales up to a more featureful A-calculus. 9 The infixr declaration 
declares that the constructor is right-associative, as usual. 

We are then confronted quickly with the decision of how to encode bound variables. 
Let’s choose de Bruijn indices [21], as these are well known and conceptually simple. 
However, instead of using natural numbers to represent our variables, we’ll use a 
custom Elem type: 

data Elem :: [a] — > a — > Type where 
EZ: : Elem (x’: xs) x 

ES :: Elem xs x —>• Elem (y ’: xs) x 

A value of type Elem xs x is a proof that x is in the list xs. This proof naturally 
takes the form of a natural number, naming the place in xs where x lives. The first 
constructor EZ is a proof that x is the first element in x ’: xs. The second constructor 
ES says that, if we know x is an element in xs, then it is also an element in y ’: xs. 
We can now write our expression type: 

data Expr :: [ 7y] —> Ty —> Type where 


Var 

Elem ctx ty 

-A Expr ctx ty 

Lam 

Expr (arg ’: ctx) res 

—t Expr ctx (arg ’:-w res) 

App : 

: Expr ctx (arg res) 

—>• Expr ctx arg —> Expr ctx res 

TT : 


Expr ctx ’Unit 


As with Elem list elt, a value of type Expr ctx ty serves two purposes: it records the 
structure of our expression, and it proves a property, namely that the expression is 

8 The skeleton of this example—using GADTs to verify the implementation of the STLC—is not 
novel, but I am unaware of a canonical reference for it. 

9 For example, see my work on glambda at https://github.com/goldfirere/glambda. 
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well-typed in context ctx with type ty. Indeed, with some practice, we can read off 
the typing rules for the simply typed A-calculus direct from Expr'a definition. In this 
way, it is impossible to create an ill-typed Expr. 

3.1.2.2 Big-step evaluator 

We now wish to write both small-step and big-step operational semantics for our 
expressions. First, we’ll need a way to denote values in our language: 

data Val: : Ty —>• Type where 

LamVal:: Expr \arg] res —>• Val (arg res ) 

TTVal :: Val ’Unit 

Our big-step evaluator has a straightforward type: 

eval:: Expr ’[] ty —>• Val ty 

This type says that a well-typed, closed expression (that is, the context is empty) can 
evaluate to a well-typed value of the same type ty. Only a type-preserving evaluator 
will have that type, so GHC can check the type-soundness of our A-calculus as it 
compiles our interpreter. 

To implement eval , we’ll need several auxiliary functions, each with an intriguing 
type: 


— Shift the de Bruijn indices in an expression 
shift :: V ctx ty x. Expr ctx ty — > Expr (x ’: ctx ) ty 
— Substitute one expression into another 
subst :: V ctx s ty. Expr ctx s —>• Expr (s ’: ctx ) ty —>• Expr ctx ty 
— Perform /3-reduction 

apply :: Val (arg res ) —>• Expr ’[] arg —> Expr ’[] res 

The type of shift is precisely the content of a weakening lemma: that we can add a 
type to a context without changing the type of a well-typed expression. The type of 
subst is precisely the content of a substitution lemma: that given an expression of 
type s and an expression of type t (typed in a context containing a variable bound 
to s), we can substitute and get a new expression of type t. The type of apply shows 
that it does /3-reduction: it takes an abstraction of type arg res and an argument 
of type arg, producing a result of type res. 

The implementations of these functions, unsurprisingly, read much like the proof 
of the corresponding lemmas. We even have to “strengthen the induction hypothesis” 
for shift and subst ; we need an internal recursive function with extra arguments. Here 
are the first few lines of shift and subst: 
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shift = go [] 

where 

go :: V ty. II ctx 0 —> Expr ( ctx 0 Hf ctx ) ty —> Expr ( ctx 0 ’-ff x ctx) ty 
go = ... 

subst e = go [ ] 

where 

go :: V ty. II ctx 0 —> Expr ( ctx 0 ’-H- s ctx ) ty —» Expr ( ctx 0 Hf ctx ) ty 
go = ... 


As many readers will be aware, to prove the weakening and substitution lemmas, it is 
necessary to consider the possibility that the context change is not happening at the 
beginning of the list of types, but somewhere in the middle. This generality is needed 
in the Lam case, where we wish to use an induction hypothesis; the typing rule for 
Lam adds the type of the argument to the context, and thus the context change is no 
longer at the beginning of the context. 

Naturally, this issue comes up in our interpreter’s implementation, too. The go 
helper functions have types generalized over a possibly non-empty context prefix, ctx 0 . 
This context prefix is appended to the existing context using Hf, the promoted form 
of the existing -H- list-append operator. (Using ’ for promoting functions is a natural 
extension of the existing convention of using ’ to promote constructors from terms to 
types; see also Section 3.1.1.2.) The go functions also fl-quantify over ctxo, meaning 
that the value of this context prefix is available in types (as we can see) and also at 
runtime. This is necessary because the functions need the length of ctx 0 at runtime, 
in order to know how to shift or substitute. Note also the syntax; II ctx 0 —where the 
fl-bound variable is followed by an —K The use of an arrow here (as opposed to a . ) 
indicates that the parameter is visible in source programs; the empty list is passed in 
visibly in the invocation of go. (See also Section 4.2.3.) The final interesting feature 
of these types is that they re-quantify ty. This is necessary because the recursive 
invocations of the functions may be at a different type than the outer invocation. The 
other type variables—which do not change during recursive calls to the go helper 
functions—are lexically bound by the V in the type signature of the outer function. 

The implementation of these functions is fiddly and uninteresting, and is omitted 
from this text. However, writing this implementation is made much easier by the 
precise types. If I were to make a mistake in the delicate de Bruijn shifting operation, 
I would learn of my mistake immediately, without any testing. In an algorithm so easy 
to get wrong, this feedback is wonderful, indeed. 

With all of these supporting functions written, the evaluator itself is dead simple: 

eval ( Var v ) = case v of { } — no variables in an empty context 

eval (Lam body ) = LamVal body 

eval (App el e2 ) = eval (apply (eval el) e2 ) 

eval TT = TTVal 
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The only curiosity here is the empty case expression in the Var case, which eliminates 
v of the uninhabited type Elem ’[ ] ty. 

3.1.2.3 Small-step stepper 

We now turn to writing the small-step semantics. We could proceed in a very similar 
fashion to the big-step semantics, by defining a step function that steps an expression 
either to another expression or to a value. But we want better than this. 

Instead, we want to ensure that the small-step semantics respects the big-step 
semantics. That is, after every step, we want the value—as given by the big-step 
semantics—to remain the same. We thus want the small-step stepper to return a 

custom datatype, marrying the result of stepping with evidence that the value of this 

result agrees with the value of the original expression: 10 

data StepResult :: Expr ’[] ty —>■ Type where 

Stepped :: II (e':: Expr ’[] ty) -4 (’eva/ e ~ ’eva/ e') =>- StepResult e 

Value :: II (v :: Val ty) -4 (’eva/ e ~ v) =>• StepResult e 


A StepResult e is the result of stepping an expression e. It either contains a new 
expression e' whose value equals e’s value, or it contains the value v that is the result 
of evaluating e. 

An interesting detail about these constructors is that they feature an equality 
constraint after a runtime argument. Currently, GHC requires that all data constructors 
take a sequence of type arguments, followed by constraints, followed by regular 
arguments. Generalizing this form poses no real difficulty, however. 

With this in hand, the step function is remarkably easy to write: 

step :: II (e :: Expr ’[] ty) —>• StepResult e 

step (Var v) = case v of { } — no variables in an empty context 

step (Lam body) = Value (LamVal body) 
step (App el e2) = case step el of 
Stepped el' ->■ Stepped (App el' e2) 

Value v —> Stepped (apply v e2) 

step TT = Value TTVal 


10 This example fails for two reasons: 

• It contains data constructors with constraints occurring after visible parameters, but GHC 
imposes rigid requirements on the shape of data constructor types. 

• Writing a type-level version of shift (automatic promotion with ’ is not yet implemented) is 
not yet possible. The problem is that one of the helper function’s arguments has a type that 
mentions the -If function, a feature that is not yet implemented. 

I do not expect fixing either of these problems to be a significant challenge. 
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Due to GHC’s ability to freely use equality assumptions, step requires no explicit 
manipulation of equality proofs. Let’s look at the App case above. We first check 
whether or not el can take a step. If it can, we get the result of the step el' and a 
proof that 'eval el ~ ’eva/ el '. This proof enters into the type-checking context and 
is invisible in the program text. On the right-hand side of the match, we conclude 
that App el e2 steps to App el’ e2. This requires a proof that ’eva/ ( App el e2) ~ 

’ eval (App el' e2). Reducing ’eva/ on both sides of that equality gives us 

’eva/ (’apply (’eva/ el) e2) ~ ’eval (’apply (’eval el ') e2). 

Since we know ’ eval el ~ ’ eval el ', however, this equality is easily solvable; GHC 
does the heavy lifting for us. Similar reasoning proves the equality in the second 
branch of the case, and the other clauses of step are straightforward. 

The ease with which these equalities are solved is unique to Haskell. I have 
translated this example to Coq, Agda, and Idris; each has its shortcomings: 

• Coq deals quite poorly with indexed types, such as Expr. The problem appears to 
stem from Coq’s weak support for dependent pattern matching. For example, if 
we inspect a ctx to discover that it is empty, Coq, by default, forgets the equality 
ctx = [ ]. It then, naturally, fails to use the equality to rewrite the types of the 
right-hand sides of the pattern match. This can be overcome through various 
tricks, but it is far from easy. Alternatively, Coq’s relatively new Program 
construct helps with this burden somewhat but still does not always work as 
smoothly as GADT pattern matching in Haskell. Furthermore, even once the 
challenges around indexed types are surmounted, it is necessary to prove that 
eval terminates—a non-trivial task—for Coq to accept the function. 

• Agda does a better job with indexed types, but it is not designed around implicit 
proof search. A key part of Haskell’s elegance in this example is that pattern¬ 
matching on a StepResult reveals an equality proof to the type-checker, and 
this proof is then used to rewrite types in the body of the pattern match. This 
all happens without any direction from the programmer. In Agda, the equality 
proofs must be unpacked and used with Agda’s rewrite tactic. 

Like Coq, Agda normally requires that functions terminate. However, we can 
easily disable the termination checker: use {-# NO_TERMINATION_CHECK #->. 

• Like Agda, Idris works well with indexed types. The eval function is, unsurpris¬ 
ingly, inferred to be partial, but this is easy enough to fix with a well-placed 
assert_total. However, Idris’s proof search mechanism is unable to find proofs 
that step is correct in the App cases. (Using an auto variable, Idris is able to find 
the proofs automatically in the other step clauses.) Idris comes the closest to 
Haskell’s brevity in this example, but it still requires two places where equality 
proofs must be explicitly manipulated. 
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3.1.2.4 Conclusion 


We have built up a small-step stepper whose behavior is verified against a big-step 
evaluator. Despite this extra checking, the step function will run in an identical manner 
to one that is unchecked—there is no runtime effect of the extra verification. We 
can be sure of this because we can audit the types involved and see that only the 
expression itself is around at runtime; the rest of the arguments (the indices and 
the equality proofs) are erased. Furthermore, getting this all done is easier and more 
straightforward in Dependent Haskell than in the other three dependently typed 
languages I tried. Key to the ease of encoding in Haskell is that Haskell does not worry 
about termination (see Section 3.3.3) and has an aggressive rewriting engine used to 
solve equality predicates. 

3.1.3 Type-safe database access with an inferred schema 

Many applications need to work in the context of some external database. Haskellers 
naturally want their interface to the database to be well-typed, and there already exist 
libraries that use (non-dependent) Haskell’s fancy types to good effect for database 
access. (See opaleye 11 for an advanced, actively developed and actively used example 
of such a library.) Dependent Haskell allows us to go one step further and use type 
inference to infer a database schema from the database access code. 

This example is inspired by the third example by Oury and Swierstra [69]; the full 
code powering the example is available online. 12 

Instead of starting with the library design, let’s start with a concrete use case. 
Suppose we are writing an information system for a university. The current task is to 
write a function that, given the name of a professor, prints out the names of students 
in that professor’s classes. There are two database tables of interest, exemplified in 
Figure 3.1 on the following page. Our program will retrieve a professor’s record and 
then look up the students by their ID number. 

Our goal in this example is understanding the broad strokes of how the database 
library works and what it is capable of, not all the precise details. If you wish to 
understand more, please check out the full source code online. 

3.1.3.1 Accessing the database 

The main worker function that retrieves and processes the information of interest from 
the database is queryDB, in Figure 3.2 on the next page. Note that this function is not 
assigned a type signature; we’ll return to this interesting point in Section 3.1.3.2. The 
queryDB function takes in the schemas for the two tables it will retrieve the data from. 
It loads the tables that correspond to the schemas; the loadTable function makes sure 
that the table (as specified by its filename) does indeed correspond to the schema. An 

11 https://github.com/tomjaguarpaw/haskell-opaleye 

12 https://github.com/goldfirere/dependent-db 
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The students table: 


last 

first 

id 

gradyear 

"Matthews" 

"Maya" 

1 

2018 

"Morley" 

"Aimee" 

2 

2017 

"Barnett" 

"William" 

3 

2020 

"Leonard" 

"Sienna" 

4 

2019 

"Oliveira" 

"Pedro" 

5 

2017 

"Peng" 

"Qi" 

6 

2020 

"Chakraborty" 

"Sangeeta" 

7 

2018 

"Yang" 

"Rebecca" 

8 

2019 


The classes table: 


name 

"Blank" 

"Eisenberg" 

"Kumar" 

"Xu" 


students course 

[2.3.7.8] "Robotics" 

[1.2.5.8] "Programming Languages" 

[3.6.7.8] "Artificial Intelligence" 

[1,3,4,5] "Graphics" 


Figure 3.1: Database tables used in Section 3.1.3. 


type NameSchema = [Col "first" String, Col "last" String] 
print Name :: Row NameSchema —>• 10 () 
print Name (first ::> last ::> _) = putStrLn (first -H- " " -H- last) 
queryDB classessch studentssch = do 

dassestab 4r- loadTable "classes.table" classes_sch 
students_tab 4— loadTable "students .table" students sch 
putStr "Whose students do you want to see? " 
prof 4— getLine 
let joined 

= project $ 

select (field @"id" @lnt L elementOf l field @"students") $ 
product ( select (field @"prof" === literal prof ) 

(read dasses tab )) 

(read students tab ) 
rows 4— query joined 
mapM_ printName rows 


Figure 3.2: The queryDB function 
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data Column = Col String Type 
type Schema = [Column] 


data Table 

data RA 

data Expr 

loadTable 

project 

select 

field 

elementOf 

product 

literal 

read 


Schema —>• Type — a table according to a schema 
Schema —> Type — a Relational /Algebra 
Schema —> Type —>• Type — an expression 
String —>• II (s :: Schema ) —»■ 10 ( Table s ) 

Subset s' s ^ RA s ^ RA s' 

Expr s Bool —^ R>A s —^ RA s 
V name ty s. In name ty s =>- Expr s ty 
Eq ty => Expr s ty —>• Expr s [ty] —>• Expr s Bool 
’ disjoint s s' ~ ’True =>- RA s ^ RA s RA (s ’-H- s') 
ty —> Expr s ty 
Table s —> RA s 


Figure 3.3: Types used in the example of Section 3.1.3. 

I/O interaction with the user then ensues, resulting in a variable pro/ 1 ' of type String 
containing the desired professor’s name. 

The joined variable then gets assigned to a large query against the database. This 
query: 

1. reads in the classes table, 

2. selects out any rows that mention the desired prof, 

3. computes the Cartesian product of these rows and all the rows in the students 
table, 

4. selects out those rows where the id field is in the students list, 

5. and finally projects out the name of the student. 

The types of the components of this query are in Figure 3.3. There are a few points of 
interest in looking at this code: 

• The query is well-typed by construction. Note the intricate types appearing in 
Figure 3.3. For example, select takes an expression used to select which rows of 
a table are preserved. This operation naturally requires an Expr s Bool, where 
s is the schema of interest and the Bool indicates that we have a Boolean 
expression (as opposed to one that results in a number, say). The RA type does 
not permit ill-typed queries, such as taking the Cartesian product of two tables 
with overlapping column names (see the type of product ), as projections from 
such a combination would be ambiguous. 
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• Use of field requires the @ invisibility override marker, as we wish to specify the 
name of the field. 

• In the first select expression, we must specify the type of the field as well as 
the name, whereas in the second select expression, we can omit the type. In the 
second case, the type can be inferred by comparison with the literal prof. In 
the first, type inference tells us that id is the element type of students, but we 
need to be more concrete than this—hence the @lnt passed to field. 

• The use of project at the top projects out the first and last name of the student, 
even though neither first nor last is mentioned there. Type inference does 
the work for us, as we pass the result of running the query to printName , which 
has a type signature that states it works over only names. 

3.1.3.2 Inferring a schema 

Type inference works to infer the type of queryDB , assigning it this whopper: 

A> :type queryDB 
queryDB 

:: II (s :: Schema) (s':: Schema) 

—> ( ’disjoint ss' ~ ’True, In "students" [ Int] (s’-H-s'), 

In "prof" String s, In "last" [Char] (s’-H-s'), 

In "id" Int (s Hf s'), In "first" [Char] (s’-H-s')) 

-> io 0 


The cavalcade of constraints are all inferred from the query above quite straightfor¬ 
wardly. 13 But how can we call queryDB satisfying all of these constraints? 

The call to queryDB appears here: 

main:: 10 () 

main = do classes sch <— loadSchema "classes.schema" 
students sch •<— loadSchema "students.schema" 

$ (checkSchema ’queryDB [ , classes_sch, 'students sch ]) 


13 What may be more surprising to the skeptical reader is that a II-type is inferred, especially if 
you have already read Chapter 6. However, I maintain that the Bake algorithm in Chapter 6 infers 
this type. The two parameters to queryDB are clearly Schemas , and the body of queryDB asserts 
constraints on these Schemas. Note that the type inference algorithm infers only relevant, visible 
parameters, but these arguments are indeed relevant and visible. The dependency comes in after 
solving, when the quantification telescope A output by the solver has constraints depend on a visible 
argument. 

As further justification for stating that Bake infers this type, GHC infers a type quite like this 
today, albeit using singletons. The appearance of singletons in the type inferred today is why this 
snippet is presented on a light yellow background. 
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The two calls to loadSchema are uninteresting. The third line of main is a Template 
Haskell [83] splice. Template Haskell is GHC’s metaprogramming facility. The quotes 
we see before the arguments to checkSchema are Template Haskell quotes, not the 
promotion ’ mark we have seen so much. 

The function checkSchema :: Name —> [Name] —>• 0 Exp takes the name of a 
function ( queryDB , in our case), names of schemas to be passed to the function 
(classessch and students_sch) and produces some Haskell code that arranges for an 
appropriate function call. ( Exp is the Template Haskell type containing a Haskell 
expression, and Q is the name of the monad Template Haskell operates under.) In order 
to produce the right function call to queryDB , checkSchema queries for the inferred 
type of queryDB. It then examines this type and extracts out all of the constraints on 
the schemas. In the produced Haskell expression, checkSchema arranges for calls to 
several functions that establish the constraints before calling queryDB. To be concrete, 
here is the result of the splice; the following code is spliced into the main function in 
place of the call to checkSchema: 


checkDisjoint classes sch studentssch 


checkin "students" 
checkin "prof" 
checkin "last" 
checkin "id" 
checkin "first" 


queryDB classes sch students sch 


[7nt] (classes sch -ff students sch ) $ 

'String classessch $ 

' ['Char] (classes_sch -ff students_sch) $ 
'Int (classes sch -H- students sch ) $ 

['Char] (classes_sch -H- students_sch) $ 


Before discussing checkDisjoint and checkin, I must explain a new piece of syntax: just 
as ’ allows us to use a term-level name in a type, the new syntax " allows us to use a 
type-level name in a term. That is all the syntax does. For example "["/nt] is the list 
type constructor applied to the type Int, not a one-element list (as it would otherwise 
appear). 

The checkDisjoint and checkin functions establish the constraints necessary to call 
queryDB. Here are their types: 

checkDisjoint :: n (schl :: Schema ) ( sch2 :: Schema ) 

-A ((’ disjoint schl sch2 ~ ’ True ) =>- r) 

-A r 

checkin :: n ( name :: String ) (ty :: Type) ( schema :: Schema) 

-A (In name ty schema =>• r ) 

-A r 


Both functions take input information 14 to validate and a continuation to call if indeed 
14 Readers might be alarmed to see here a Type being passed at runtime. After all, a key feature 
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the input is valid. In this implementation, both functions simply error (that is, return 
X) if the input is not valid, though it would not be hard to report an error in a suitable 
monad. 


3.1.3.3 Checking inclusion in a schema 

It is instructive to look at the implementation of checkin: 

checkin :: II ( name :: String ) (ty :: Type) ( schema :: Schema ) 

—>• (In name ty schema =>- r) 

-A r 

checkin name _ [] _ 

= error ("Field " show name -H- " not found. ") 
checkin name ty (Col name' ty’: rest) k 
= case (name ‘eq 1 name', ty ‘eq‘ ty') of 
(Just Reft, Just Refl ) —> k 

(Just _ f , _) —> error ("Found " -H- show name -H- 

" but it maps to " -H- show ty') 
—> checkin name ty rest k 


This function searches through the Schema (which, recall, is just a [Column]) for the 
desired name and type. If the search fails or the search find the column associated with 
the wrong type, checkin fails. Otherwise, it will eventually call k, the continuation 
that can now assume In name ty schema. The constraint In is implemented as a 
class with instances that prove that the (name, ty) pair is indeed in schema whenever 
In name ty schema holds. 

The checkin function makes critical use of a new function eg: 15 

class Eq a where 

eg :: II (x :: a) (y :: a) —> Maybe (x y) 


of Dependent Haskell is type erasure! However, passing types at runtime is sometimes necessary, 
and using the type Type to do so is a natural extension of what is done today. Indeed, today’s 
TypeRep (explored in detail by Peyton Jones et al. [75]) is essentially a singleton for Type. As 
Dependent Haskell removes other singletons, so too will it remove TypeRep in favor of dependent 
pattern matching on Type. As with other aspects of type erasure, users will choose which types to 
erase by the choice between n-quantification and a V-quantification. 

15 I present eq here as a member of the ubiquitous Eq class, as a definition for eq should be writable 
whenever a definition for == is. (Indeed, == could be implemented in terms of eq.) I do not, however, 
expect that eq will end up living directly in the Eq class, as I doubt the Haskell community will 
permit Dependent Haskell to alter such a fundamental class. Nevertheless, the functionality sported 
by eq will be a common need in Dependent Haskell code, and we will need to find a suitable home 
for the function. 
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This is just a more informative version of the standard equality operator ==. When 
two values are eg, we can get a proof of their equality. This is necessary in checkin, 
where assuming this equality is necessary in order to establish the In constraint before 
calling the constrained continuation k. 

3.1.3.4 Conclusion 

This example has highlighted several aspects of Dependent Haskell: 

• Writing a well-typed database access is well within the reach of Dependent 
Haskell. Indeed, much of the work has already been done in released libraries. 

• Inferring the type of queryDB is a capability unique to Dependent Haskell among 
dependently typed languages. Other dependently typed languages require type 
signatures on all top-level functions; this example makes critical use of Haskell’s 
ability to infer a type in deriving the type for queryDB. 

• Having dependent types in a large language like Haskell sometimes shows 
synergies with other aspects of the language. In this example, we used Template 
Haskell to complement our dependent types to achieve something neither one 
could do alone: Template Haskell’s ability to inspect an inferred type allowed us 
to synthesize the runtime checks necessary to prove that a call to queryDB was 
indeed safe. 

3.1.4 Machine-checked sorting algorithms 

Using dependent types to check a sorting algorithm is well explored in the literature 
(e.g., [1, 61]). These algorithms can also be translated into Haskell, as shown in my 
prior work [25, 30]. I will thus not go into any detail in the implementation here. 

At the bottom of one implementation 16 appears this function definition: 

mergeSort:: [Integer] —>• [Integer], 

Note that the type of the function is completely ordinary—there is no hint of the rich 
types that lurk beneath, in its implementation. It is this fact that makes machine- 
checked algorithms, such as sorting, interesting in the context of Haskell. 

A Haskell programming team may make a large application with little use for 
fancy types. Over time, the team notice bugs frequently appearing in a gnarly section 
of code (like a sorting algorithm, or more realistically, perhaps, an implementation of 
a cryptographic primitive), and they decide that they want extra assurances that the 
algorithm is correct. That one algorithm—and no other part of the large application— 
might be rewritten to use dependent types. Indeed any of the examples considered in 

16 https://github.com/goldfirere/nyc-hug-oct2014/blob/master/0rdList.hs 
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this chapter can be hidden beneath simply typed interfaces and thus form just one 
component of a larger, simply typed application. 


3.2 Encoding hard-to-type programs 

3.2.1 Variable-arity zipWith 

The Data. List Haskell standard library comes with the following functions: 

map :: (a —>■ b) —>■ [a] —>• [ b] 
zipWith :: (a —>■ b —>■ c) —>■ [a] -4- [6] —[c] 
zipWith3 :: (a —> b —> c —> d) —t [a] —> [6] —> [c] —>• [d] 
zipWith4 :: (a —>■ b —>■ c —>■ d —>■ e) —>■ [a] —>■ [6] —>■ [c]> [d] —>■ [e] 


Let’s pretend to rename map to zipWithl and zipWith to zipWith2. This sequence 
continues up to zipWith7. The fact that these are different functions means that the 
user must choose which one to use, based on the arity of the function to be mapped 
over the lists. However, forcing the user to choose this is a bit silly: the type system 
should be able to discern which zipWith is correct based on the type of the function. 
Dependent Haskell gives us the power to write such a variable-arity zipWith function. 17 

Let’s build up our solution one step at a time. We’ll first focus on building a 
zipWith that is told what arity to be; then we’ll worry about inferring this arity. 

Recall the definition of natural numbers from Section 3.1.1: 

data Nat = Zero \ Succ Nat 

What will the type of our final zipWith be? It will first take a function and then 
several lists. The types of these lists are determined by the type of the function passed 
in. For example, suppose our function f has type Int —> Bool —> Double , then the type 
of zipWith should be ( Int —» Bool —» Double ) —> [Int] -% [Bool] —> [Double]. Thus, we 
wish to take the type of the function and apply the list type constructor [ ] to each 
component of it. 

Before we write the code for this operation, we pause to note an ambiguity in this 
definition. Both of the following are sensible concrete types for a zipWith over the 
function f: 

zipWith :: (Int —> Bool —>■ Double ) 

-f [Int] —>■ [Bool —>■ Double] 
zipWith :: (Int —>■ Bool —>■ Double ) 

—» [Int] —>■ [Bool] —> [Double] 

17 This example is adapted from my prior work [31]. 
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The first of these is essentially map ; the second is the classic function zipWith that 
expects two lists. Thus, we must pass in the desired number of parameters to apply 
the list type constructor to. The function to apply these list constructors is named 
Listify: 

type family Listify (n :: Nat ) arrows where 
Listify ’Zero a = [a] 

Listify (’Succ n ) (a —)• b) = [a] — > Listify n b 

We now need to create some runtime evidence of our choice for the number of 
arguments. This will be used to control the runtime operation of zipWith —after all, our 
function must have both the correct behavior and the correct type. We use a GADT 
NumArgs that plays two roles: it controls the runtime behavior as just described, and 
it also is used as evidence to the type checker that the number argument to Listify is 
appropriate. After all, we do not want to call Listify 2 ( Int —> Bool), as that would be 
stuck. By pattern-matching on the NumArgs GADT, we get enough information to 
allow Listify to fully reduce. 

data NumArgs :: Nat —> Type —>• Type where 

NAZero ::V a. NumArgs ’Zero a 

NASucc :: V a b (n:: Nat). NumArgs n b —>■ NumArgs (’Succ n) (a —>■ b) 

We now write the runtime workhorse listApply, with the following type: 

listApply :: NumArgs n a —> [a] —> Listify n a 

The first argument is the encoding of the number of arguments to the function. The 
second argument is a list of functions to apply to corresponding elements of the lists 
passed in after the second argument. Why do we need a list of functions? Consider 
evaluating zipWith (+) [1,2] [3,4], where we recur not only on the elements in the 
list, but on the number of arguments. After processing the first list, we have to be 
able to apply different functions to each of the elements of the second list. To wit, we 
need to apply the functions [(1+), (2+)] to corresponding elements in the list [3,4], 
(Here, we are using Haskell’s “section” notation for partially-applied operators.) 

Here is the definition of listApply : 

listApply NAZero fs = fs 

listApply (NASucc na) fs = 

Xargs —>• listApply na (apply fs args) 
where apply :: [a —>■ b] ->• [a] ->■ [b] 

apply (f : fs) (x : xs) = (f x: apply fs xs) 
appfy - - = [] 

It first pattern-matches on its first argument. In the NAZero case, each member of the 
list of functions passed in has 0 arguments, so we just return the list. In the NASucc 
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case, we process one more argument ( args ), apply the list of functions fs respectively 
to the elements of args , and then recur. Note how the GADT pattern matching is 
essential for this to type-check—the type checker gets just enough information for 
Listify to reduce enough so that the second case can expect one more argument than 
the first case. 

Inferring arity In order to infer the arity, we need to have a function that counts 
up the number of arrows in a function type: 

type family CountArgs (f :: Type) :: Nat where 
CountArgs (a —>• b) = ’Succ (CountArgs b ) 

CountArgs result = ’Zero 

The ability to write this function is unique to Haskell, where pattern-matching on 
proper types (of kind Type) is allowed. 

We need to connect this type-level function with the term-level GADT NumArgs. 
We use Haskell’s method for reflecting type-level decisions on the term level: type 
classes. The following definition essentially repeats the definition of NumArgs, but 
because this is a definition for a class, the instance is inferred rather than given 
explicitly: 

class CNumArgs (numArgs :: Nat ) (arrows :: Type) where 
getNA :: NumArgs numArgs arrows 
instance CNumArgs ’Zero a where 
getNA = NAZero 
instance CNumArgs n b => 

CNumArgs ( ’Succ n) (a —>• b) where 
getNA = NASucc getNA 

Note that the instances do not overlap; they are distinguished by their first parameter. 

It is now straightforward to give the final definition of zipWith, using the extension 
ScopedTypeVariables to give the body of zipWith access to the type variable f: 

zipWith :: V f. CNumArgs (CountArgs f ) f 
f — > Listify (CountArgs f ) f 

zipWith fun 

= listApply (getNA :: NumArgs (CountArgs f) f) (repeat fun ) 

The standard Haskell function repeat creates an infinite list of its one argument. 

The following examples show that zipWith indeed infers the arity: 

example 1 = zipWith (&&) [False, True, False] [True, True, False] 
example 2 = zipWith ((+) :: Int —>• Int —>■ Int ) [1, 2, 3] [4, 5, 6] 
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concat :: Int —>• Char —>• Double —> String 
concat a b c = (show a) -H- (show b) -H- (show c ) 
example 3 = zipWith concat [1,2,3] [’a’, ’b’, ’c’] 

[3.14, 2.1728,1.01001] 

In example 2 , we must specify the concrete instantiation of (+). In Haskell, built-in 
numerical operations are generalized over a type class Num. In this case, the operator 
(+) has the type Num a =>• a —>• a —> a. Because it is theoretically possible (though 
deeply strange!) for a to be instantiated with a function type, using (+) without an 
explicit type will not work—there is no way to infer an unambiguous arity. Specifically, 
CountArgs gets stuck. CountArgs (a —» a —>• a) simplifies to Succ (Succ (CountArgs a)) 
but can go no further; CountArgs a will not simplify to Zero, because a is not apart 
from b —> c. 

3.2.2 Typed reflection 

Reflection is the act of reasoning about a programming language from within programs 
written in that language. 18 In Haskell, we are naturally concerned with reflecting the 
rich language of Haskell types. A reflection facility such as the one described here 
will be immediately applicable in the context of Cloud Haskell. Cloud Haskell [35] is 
an ongoing project, aiming to support writing a Haskell program that can operate 
on several machines in parallel, communicating over a network. To achieve this goal, 
we need a way of communicating data of all types over a wire—in other words, we 
need dynamic types. On the receiving end, we would like to be able to inspect a 
dynamically typed datum, figure out its type, and then use it at the encoded type. 
For more information about how kind equalities fit into Cloud Haskell, please see the 
GHC wiki at https://ghc.haskell.org/trac/ghc/wiki/DistributedHaskell. 

Reflection of this sort has been possible for some time using the Typeable mecha¬ 
nism [53]. However, the lack of kind equalities—the ability to learn about a type’s 
kind via pattern matching—has hindered some of the usefulness of Haskell’s reflection 
facility. In this section, we explore how this is the case and how the problem is fixed. 

3.2.2.1 Heterogeneous propositional equality 

Kind equalities allow for the definition of heterogeneous propositional equality, a natural 
extension to the propositional equality described in Section 2.4: 

data (a :: kfl) :m:(b :: k 2 ) where 
HRefl :: a:~: a 


18 Many passages in this example are expanded upon in my prior work [75]. 
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Pattern-matching on a value of type a b to get HRefl , where a :: Ai and b :: A 2 , tells 
us both that Ay ~ /c 2 and that a ~ b. As we’ll see below, this more powerful form of 
equality is essential in building the typed reflection facility we want. 

3.2.2.2 Type representation 

Here is our desired representation: 19 
data TyCon (a :: A) 

— abstract; the type Int is represented by the one value of type TyCon Int 
data TypeRep (a :: A) where 
TyCon :: TyCon a —> TypeRep a 
TyApp :: TypeRep a —>• TypeRep b —> TypeRep (a 6) 

The intent is that, for every new type declared, the compiler would supply an appropri¬ 
ate value of the TyCon datatype. The type representation library would supply also the 
following function, which computes equality over TyCons , returning the heterogeneous 
equality witness: 

eqTyCon :: V (a :: Ay) (b::k 2 ). 

TyCon a —>• TyCon b —>• Maybe (a 6) 


It is critical that this function returns (:«:), not (:~:). This is because TyCons exist 
at many different kinds. For example, Int is at kind Type, and Maybe is at kind 
Type —y Type. Thus, when comparing two TyCon representations for equality, we 
want to learn whether the types and the kinds are equal. If we used (:~:) here, then 
the eqTyCon could be used only when we know, from some other source, that the 
kinds are equal. 

We can now easily write an equality test over these type representations: 


eqT :: V (a :: Ai) (b :: A 2 ). 

TypeRep a —>• TypeRep b ->■ Maybe (a :«: b) 
eqT (TyCon tl) (TyCon t2 ) = eqTyCon tl t2 

eqT (TyApp al bl) (TyApp a2 b2) 

| Just HRefl<- eqT al a2 
, Just HRefl <- eqT bl b2 = Just HRefl 
eqT _ _ = Nothing 


Note the extra power we get by returning Maybe (a b) instead of just a Bool. 
When the types are indeed equal, we get evidence that GHC can use to be aware of 

19 This representation works well with an open world assumption, where users may introduce new 
type constants in any module. See my prior work [75, Section 4] for more discussion on this point. 
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this type equality during type checking. A simple return type of Bool would not give 
the type-checker any information. 

3.2.2.3 Dynamic typing 

Now that we have a type representation with computable equality, we can package 
that representation with a chunk of data, and so form a dynamically typed package: 

data Dyn where 

Dyn :: V (a :: Type). TypeRep a —► a —► Dyn 

The a type variable there is an existential type variable. We can think of this type 
as being part of the data payload of the Dyn constructor; it is chosen at construction 
time and unpacked at pattern-match time. Because of the TypeRep a argument, we can 
learn more about a after unpacking. (Without the TypeRep a or some other type-level 
information about a, the unpacking code must treat a as an unknown type and must 
be parametric in the choice of a.) 

Using Dyn, we can pack up arbitrary data along with its type and push that data 
across a network. The receiving program can then make use of the data, without 
needing to subvert Haskell’s type system. This type representation library must be 
trusted to recreate the TypeRep on the far end of the wire, but the equality tests 
above and other functions below can live outside the trusted code base. 

Suppose we were to send an object with a function type, say Bool —► Int over the 
network. Let’s ignore here the complexities of actually serializing a function—there 
is a solution to that problem 20 , but here we are concerned only with the types. We 
would want to apply the received function to some argument. What we want is this: 

dyn Apply :: Dyn —>• Dyn —> Maybe Dyn 

The function dyn Apply applies its first argument to the second, as long as the types 
line up. The definition of this function is fairly straightforward: 

dyn Apply (Dyn (TyApp 

(TyApp (TyCon tarrow) targ ) 
tres) 
fun) 

(Dyn targ’ arg) 

| Just HRefl <— eqTyCon tarrow (tyCon :: TyCon (—>■)) 

, Just HRefl t— eqT targ targ' 

= Just (Dyn tres (fun arg)) 

dynApply _= Nothing 


20 https://ghc.haskell.org/trac/ghc/wiki/StaticPointers 


38 



We first match against the expected type structure—the first Dyn argument must be a 
function type. We then confirm that the TyCon tarrow is indeed the representation for 
(—>•) (the construct tyCon:: TyCon (—>•) retrieves the compiler-generated representation 
for (—>•)) and that the actual argument type matches the expected argument type. If 
everything is good so far, we succeed, applying the function in fun arg. 

3.2.2.4 Conclusion 

Heterogeneous equality is necessary throughout this example. It first is necessary in the 
definition of eqT. In the TyApp case, we compare al to a2. If we had only homogeneous 
equality, it would be necessary that the types represented by al and a2 be of the same 
kind. Yet, we can’t know this here! Even if the types represented by TyApp al bl and 
TyApp a2 b2 have the same kind, it is possible that al and a2 would not. (For example, 
maybe the type represented by al has kind Type —y Type and the type represented 
by a2 has kind Bool —> Type.) With only homogeneous equality, we cannot even 
write an equality function over this form of type representation. The problem repeats 
itself in the definition of dynApply, when calling eqTyCon tarrow TArrow. The call to 
eqT in dynApply , on the other hand, could be homogeneous, as we would know at 
that point that the types represented by targ and targ' are both of kind Type. 

In today’s Haskell, the lack of heterogeneous equality means that dynApply must 
rely critically on unsafeCoerce. With heterogeneous equality, dynApply can remain 
safely outside the trusted code base. 

3.2.3 Algebraic effects 

Brady [8] describes an approach to the challenge of embedding side effects into a pure, 
functional language. His approach is to use composable algebraic effects, implemented 
as a domain-specific language embedded in Idris [9], a full spectrum dependently typed 
language. This technique is meant to contrast with Haskell’s monad transformers [55]. 
Brady’s library, Effects, is translatable directly into Dependent Haskell. With heavy 
use of singletons, all of the code described in the original paper is even implementable 
in GHC 8. 21 

3.2.3.1 Example 1: an simple expression interpreter 

To give you an idea of the power and flexibility of the algebraic effects approach, 
let’s look at a function that interprets a simple expression language. 22 Here is the 
expression AST: 

data Expr = Val Nat \ Add Expr Expr \ Var String \ Random Nat 

21 The code is available at https://github.com/goldfirere/thesis/tree/master/effects. It 
does not compile with GHC 8.0.1 due to a small implementation bug. The fix is in the latest 
development version of GHC and may be available in GHC 8.0.2. 

22 This example is adapted from Brady [8, Section 2.1.3]. 




Expressions can contain literal numbers, 23 addition, variable references, and naturals 
randomly generated up to some specified limit. In the version we will consider, the 
interpreter is instrumented to print out the value of every random number generated. 
Thus the interpreter needs four different effectful capabilities: the ability to deal with 
errors (in case a named variable does not exist), the ability to write output, access to 
a pseudo-random number generator, and an ambient environment of defined variables. 
This ambient environment has type Vars, an association list mapping variable names 
to their values: 

type Vars = [(String, Nat)} 

With all that in mind, here is the evaluator: 

eval :: Handler StdIO e 

=> Expr ->• Eff e ’[EXCEPTION String, STDIO, RND, STATE Vars} Nat 
eval (Val x ) = return x 

eval (Var x) = do vs <— get 

case lookup x vs of 

Nothing —>• raise ("Unknown var: " -H-x) 

Just val —>• return val 

eval (Add I r) — (+) ($) eval I (*) eval r 

eval (Random upper) = do num i— rndNat 0 upper 

putStrLn ("Random value: " -H- show num) 
return num 

Let’s first look at the type of eval, with our goal being a general understanding of 
what this technique brings us, not working out all the details. 

The return type of this function is a specialization of Eff, a type defined by the 
Effects library. Eff is not a monad; the use of do-notation in the code in this section is 
enabled by the GHC extension RebindableSyntax. With RebindableSyntax, GHC 
uses whatever symbols are in scope to implement various features. In our case, Effects 
defines » and operators which work over Eff. 

Eff takes three parameters: an underlying effect handler e, a type-level list of 
capabilities, and the return type of the computation. The underlying effect handler 
must be able to handle read and write commands. We would generally expect this to 
be 10, but an environment with an input list of strings and an output list of strings 
could be used to model I/O in a pure environment. The list of capabilities is better 
viewed as a set, as the order in this list is immaterial. Fancy footwork done by the 
types of the operations provided by the capabilities (like get or rndNat) looks up the 
capability in the list, regardless of order. 

23 I have restricted this and other examples to work with naturals only. This restriction is in place 
solely to play nicely with the use of singletons to translate the Idris library into a form compatible 
with GHC 8. In a full Dependent Haskell implementation, this restriction would not be necessary. 
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Once we’ve absorbed the type of eval, its body is rather uninteresting—and that’s 
exactly the point! We need not lift one capability through another (as must be done 
with monad transformers) nor give any indication of how our capabilities are structured. 
It all just works. 

With eval in hand, it is straightforward to write the function that actually can 
evaluate an expression: 

run Eva I:: Vars —> Expr —»■ 10 Nat 

runEval env expr = run (() :> () :> 123 :> env :> Empty) ( eval expr) 

The first argument to the Effects library function run is an environment of resources, 
where each resource is associated with a capability. While the order of capabilities does 
not matter in the body of eval , its order must match up with the order of resources 
given when running an Eff computation. In this case, the EXCEPTION String and 
STDIO capabilities have no associated resource (the entries in the environment are 
both ()). The RND capability uses a random generation seed (123 in our case), and 
the STATE Vars needs the initial state, passed as a parameter to runEval. 

Having defined all of the above, we can now observe this interaction: 

A> runEval [("x",3)] ( Var "x" l Add l Random 12) 

Random value: 1 
4 

In this output, the 4 at the end is the result of evaluating the expression, which adds 
the value of "x", 3, to the pseudo-random number 1. 

3.2.3.2 Automatic lifting 

In the example above, we can use the STATE capability with its get accessor, despite 
the fact that STATE is buried at the bottom of the list of capabilities. This is done by 
get' s rather clever type: 

get :: n (prf :: SubList '[STATE x] xs). 

prf ~ 'findSubListProof '[STATE x] xs 
=> EffM m xs (UpdateWith '[STATE x] xs prf) x 


The function get takes in a proof that '[STATE x] xs is a sublist of xs, the list of 
capabilities in the result type. (EffM is a generalization of Eff that allows for the 
capabilities to change during a computation. It lists the “before” capabilities and the 
“after” capabilities. Eff is just a type synonym for EffM with both lists the same.) 
Despite taking the proof in as an argument, get requires that the proof be the one 
found by the findSubListProof function. In this way, the calling code does not need to 
write the proof by hand; it can be discovered automatically. However, note that the 
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proof is Il-bound—it is needed at runtime because each capability is associated with a 
resource, stored in a list. The proof acts as an index into that list to find the resource. 

In Idris, get’s type is considerably simpler: get :: EFF m ’[STATE x] x. This works in 
Idris because of Idris’s implicits feature, whereby a user can install an implicit function 
to be tried in the case of a type mismatch. In our case here, the list of capabilities in 
get’s type will not match the larger list in eval’s type, triggering a type error. The 
Effects library provides an implicit lifting operation which does the proof search I 
have encapsulated into findSubListProof. While it is conceivable to consider adding 
such an implicits feature to Haskell, doing so is well beyond this dissertation. In the 
case of my translation of Effects, the lack of implicits bites, but not in a particularly 
troublesome way; the types of basic operations like get just get a little more involved. 

3.2.3.3 Example 2: Working with files 

Brady [8, Section 2.2.5] also includes an example of how Effects can help us work with 
files. We first define a readLines function that reads all of the lines in a file. This uses 
primitive operations readLine and eof. 

readLines :: EFF 10 ’[FILEIO (OpenFile ’Read)] [String] 
readLines = readAcc [] 

where 

readAcc acc = doef- eoF 
if ( not e) 

then do str 4— readLine 

readAcc (str : acc) 
else return (reverse acc) 


Once again, let’s look at the type. The only capability asserted by readLines is the 
ability to access one hie opened for reading. The implementation is straightforward. 
The function readLines is used by readFile : 

readFile :: String ->■ EFF 10 ’[FILE IO (), STDIO, EXCEPTION String] [String] 
readFile path 

= catch (do _ 4 — open path Read 

test Flere (raise ("Cannot open file: " -H- path)) $ 
do lines 4 — HFt readLines 
close @ Read 
return lines) 

(A err —> do putStrLn ("Failed: " -ff err) 
return []) 


The type of readFile is becoming routine: it describes an effectful computation that can 
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access files (with none open), do input/output, and raise exceptions. The underlying 
handler is Haskell’s 10 monad, and the result of running readFile is a list of strings. 

The body of this function, however, deserves scrutiny, as the type system is working 
hard on our behalf throughout this function. The first line calls the Effects library 
function open, which uses the FILEIO capability. Here is a simplified version of its 
type, where the automatic lifting mechanism (Section 3.2.3.2) is left out: 

open :: String —>• n (m :: Mode ) 

EffM e \FILE_IO ()] \FILE_IO (Either () (OpenFile m))] Bool 


The function open takes the name of a file and whether to open it for reading or 
writing. Its return type declares that the open operation starts with the capability of 
file operations with no open file but ends with the capability of file operations either 
with no open file or with a file opened according to the mode requested. Recall that 
EffM is a generalization of Eff that declares two lists of capabilities: one before an 
action and one after it. The Either in open’s type reflects the possibility of failure. 
After all, we cannot be sure that open will indeed result in an open file. 24 The return 
value of type Bool indicates success or failure. 

After running open, readFile uses test, another Effects function, with the following 
type: 


test :: n (prf :: EffElem e (Either I r) xs ) 

—» EffM m (UpdateResTylmm xs prf I ) xs't 
—> EffM m (UpdateResTylmm xs prf r) xs't 
—y EffM m xs xs't 


Without looking too closely at that type, we can surmise this: 

• The starting capability set, xs, contains an effect with an Either I r resource. 

• The caller of test must provide a proof prf of this fact. ( EffElem is a rather 
standard datatype that witnesses the inclusion of some element in a list, tailored 
a bit to work with capabilities.) 

• The next two arguments of test are continuations to pursue depending on the 
status of the Either. Note that the first works with / and the second with r. Both 
continuations must result in the same ending capability set xs'. 

24 Readers may be wondering at this point how Effects deals with the possibility of multiple open 
files. The library can indeed handle this possibility through listing FILE_IO multiple times in the 
list of capabilities. Effects includes a mechanism for labeling capabilities (not described here, but 
implemented in Haskell and described by Brady [8]) that can differentiate among several FILE_IO 
capabilities. 
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• The test operator itself takes the capability set from xs to xs'. 


In our case, test is meant to check the Either () (OpenFile ’Read), stored in the first 
capability. (Here is the proof that the capability we seek is first in the list.) If the 
Either is Left, raise an exception. Otherwise, we know that the open succeeded, and 
the inner do block can work with a capability FILEIO (OpenFile ’Read). 

The inner do block runs readLines, using lift because the type of readLines assumes 
only the one FILEIO capability, and read File has more than just that. The same 
automatic proof search facility described earlier works with explicit lifts. 

The use of close here is again interesting, because omitting it would be a type 
error. Here is close’s type (again, eliding the lifting machinery): 

close :: V m e. EffM e ’[FILE IO (OpenFile m)] ’[FILE IO ()] () 


It takes an OpenFile and closes it. Forgetting this step would be a type error because 
test requires that both paths result in the same set of capabilities. The failure path 
from test has no open files at the end, and so the success path must also end with no 
open files. The type of close achieves this. 

A careful reader will note that we have to specify the Read invisible parameter 
to close. This is necessary to support the automatic lifting mechanism. Without 
knowing that it is searching for FILE IO (OpenFile Read), it gets quite confused; 
looking for FILE IO (OpenFile m) is just not specific enough. It is conceivable that 
this restriction could be lifted with a cleverer automatic lifting mechanism or a 
type-checker plugin [22, 38]. 

All of the code described above is wrapped in a catch in order to deal with any 
possible exception; catch is not intricately typed and does not deserve further study 
here. 

Having written readFile, we can now use it: 

printFile :: FilePath —> 10 () 
printFile filepath 

= do Is <- run (() :> () :> () :> Empty ) (readFile filepath) 
mapM_ putStrLn Is 

The return type of printFile is just the regular Haskell 10 monad. Due to the way 
GHC’s RebindableSyntax extension works, printFile must be written in a separate 
module from the code above in order to access the usual monadic meaning of do. 

This example has shown us how the Effects not only makes it easy to mix and 
match different effects without the quadratic code cost of monad transformers, but 
it also helps us remember to release resources. Forgetting to release a resource has 
become a type error. 
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3.2.3.4 Example 3: an interpreter for a well-typed imperative language 

The final example with Effects is also the culminating example by Brady [8, Section 4]: 
an interpreter for an imperative language with mutable state. The goal of presenting 
this example is simply to show that Effects scales to ever more intricate types, even 
in its translation to Haskell. Accordingly, I will be suppressing many details in this 
presentation. The curious can read the full source code online. 25 
This language, Imp, contains both expressions and statements: 

data Ty = ... — types in Imp 

interpTy :: Ty —> Type — consider a, Ty as & real Haskell Type 
data Expr :: V n. Vec Ty n —>• Ty —>• Type where ... 
data Imp :: V n. Vec Ty n —>• Ty —>• Type where ... 


Following the implementation in Idris, my translation uses a deep embedding for the 
types, using the datatype Ty instead of Haskell’s types. This is purely a design choice; 
using Haskell’s types works just as well. 26 

Expressions and statements (the datatype Imp ) are parameterized over a vector 
of types given to de Bruijn-indexed variables. Both expressions and statements also 
produce an output value, included in their types above. Thus, an expression of type 
Expr g t has type t in the typing context g. 

Let’s focus on the statement form that introduces a new, mutable variable: 

data Imp ::Vn. Vec Ty n —»• Ty —>• Type where 
Let :: V t g u. Expr g t —> Imp (t :&zg) u —> Imp g u 


The variable, of type t, is given an initial value by evaluating the Expr g t. The body 
of the Let is an Imp (t :&g) u —that is, a statement of type u in a context extended 
by t. (The operator :& is the cons operator for Vec, here.) 

Here is how such a statement is interpreted: 

25 https://github.com/goldfirere/thesis/blob/master/effects/Sec4.hs 
26 Interestingly, the use of a deep embedding in my implementation means that I have to label 
interpTy as injective [86]. Otherwise, type inference fails. Idris’s type inference algorithm must 
similarly use injectivity to accept this program. 
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interp :: V g t. Imp g t ->■ E/F 10 '[STDIO , R/VD, STATE (Vars g)} ('interpTy t) 
interp (Let @t' e sc) 

= do e'f- lift (eval e) 

vars <- get @(Vars g ) 
putM @(Vars g) (eV vars) 
res interp sc 

(_: A vars') 4- get @(Vars (t' :&g)) 
putM @(Vars (t':&g)) vars' 
return res 


I will skip over most of the details here, making only these points: 

• It is necessary to use the @ invisibility override (Section 4.2.3.1) several times 
so that the automatic lifting mechanism knows what to look for. Alternatives to 
the approach seen here include using explicit labels on capabilities (see Brady [8, 
Section 2.1.2]), writing down the index of the capability desired, or implementing 
a type-checker plugin to help do automatic lifting. 

• The putM function (an operation on STATE ) changes the type of the stored 
state. In this case, the stored state is a vector that is extended with the new 
variable. We must, however, remember to restore the original state, as otherwise 
the final list of capabilities would be different than the starting list, a violation of 
interp' s type. (Recall that Eff , in interp' s type, requires the same final capability 
set as its initial capability set.) 

• The eval function (elided from this text) uses a smaller set of capabilities. Its 
use must be lifted. 

Despite the ever fancier types seen in this example, Haskell still holds up. The 
requirement to specify the many invisible arguments (such as @(Vars g)) is indeed 
regrettable; however, I feel confident that some future work could resolve this pain 
point. 

3.2.3.5 Conclusion 

The Effects library is a major achievement in Idris and shows some of the power 
of dependent types for practical programming. I have shown here that this library 
can be ported to Dependent Haskell, where it remains just as useful. Perhaps as 
Dependent Haskell is adopted, more users will prefer to use this approach over monad 
transformers. 
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3.3 Why Haskell? 

There already exist several dependently typed languages. Why do we need another? 
This section presents several reasons why I believe the work described in this disserta¬ 
tion will have impact. 

3.3.1 Increased reach 

Haskell currently has some level of adoption in industry. 27 Haskell is also used as the 
language of choice in several academic programs used to teach functional programming. 
There is also the ongoing success of the Haskell Symposium. These facts all indicate 
that the Haskell community is active and sizeable. If GHC, the primary Haskell 
compiler, offers dependent types, more users will have immediate access to dependent 
types than ever before. 

The existing dependently typed languages were all created, more or less, as play¬ 
grounds for dependently typed programming. For a programmer to choose to write her 
program in an existing dependently typed language, she would have to be thinking 
about dependent types (or the possibility of dependent types) from the start. However, 
Haskell is, first and foremost, a general purpose functional programming language. A 
programmer might start his work in Haskell without even being aware of dependent 
types, and then as his experience grows, decide to add rich typing to a portion of his 
program. 

With the increased exposure GHC would offer to dependent types, the academic 
community will gain more insight into dependent types and their practical use in 
programs meant to get work done. 

3.3.2 Backward-compatible type inference 

Working in the context of Haskell gives me a stringent, immovable constraint: my work 
must be backward compatible. In the new version of GHC that supports dependent 
types, all current programs must continue to compile. In particular, this means that 
type inference must remain able to infer all the types it does today, including types 
for definitions with no top-level annotation. Agda and Idris require a top-level type 
annotation for every function; Coq uses inference where possible for top-level definitions 
but is sometimes unpredictable. Furthermore, Haskellers expect the type inference 
engine to work hard on their behalf; they wish to rarely rely on manual proving 
techniques. 

27 At the time of writing, https://wiki.haskell.org/Haskell_in_industry lists 81 companies 
who use Haskell to some degree. That page, of course, is world-editable and is not authoritative. 
However, I am personally aware of Haskell’s (growing) use in several industrial settings, and I 
have seen quite a few job postings looking for Haskell programmers in industry. For example, see 
http://functionalj obs.com/j obs/search/?q=haskell. 
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The requirement of backward compatibility keeps me honest in my design of type 
inference—I cannot cheat by asking the user for more information. The technical 
content of this statement is discussed in Chapter 6 by comparison with the work of 
Vytiniotis et al. [99] and Eisenberg et al. [33]. See Sections 6.8.2 and 6.8.3. A further 
advantage of working in Haskell is that the type inference of Haskell is well studied in 
the literature. This dissertation continues this tradition in Chapter 6. 

3.3.3 No termination or totality checking 

Many dependently typed languages today strive to be proof systems as well as 
programming languages. These care deeply about totality: that all pattern matches 
consider all possibilities and that every function can be proved to terminate. Coq 
does not accept a function until it is proved to terminate. Agda behaves likewise, 
although the termination checker can be disabled on a per-function basis. Idris 
embraces partiality, but then refuses to evaluate partial functions during type-checking. 
Dependent Haskell, on the other hand, does not care about totality. 

Dependent Haskell emphatically does not strive to be a proof system. In a proof 
system, whether or not a type is inhabited is equivalent to whether or not a proposition 
holds. Yet, in Haskell, all types are inhabited, by Y and other looping terms, at a 
minimum. Even at the type level, all kinds are inhabited by the following type family, 
defined in GHC’s standard library: 

type family Any :: k — no instances 

The type family Any can be used at any kind, and so inhabits all kinds. 

Furthermore, Dependent Haskell has the Type: Type axiom, meaning that instead 
of having an infinite hierarchy of universes characteristic of Coq, Agda, and Idris, 
Dependent Haskell has just one universe, which contains itself. It is well known that 
self-containment of this form leads to logical inconsistency by enabling the construction 
of a looping term [36], but I am unbothered by this—Haskell has many other looping 
terms, too! (See Section 4.4.1 for more discussion on this point.) By allowing ourselves 
to have Type: Type, the type system is much simpler than in systems with a hierarchy 
of universes. 

There are two clear downsides of the lack of totality: 

• What appears to be a proof might not be. Suppose we need to prove that type r 
equals type a in order to type-check a program. We can always use _L :: r :«: a 
to prove this equality, and then the program will type-check. The problem will 
be discovered only at runtime. Another way to see this problem is that equality 
proofs must be run, having an impact on performance. However, note that we 
cannot use the bogus equality without evaluating it; there is no soundness issue. 
This drawback is indeed serious, and important future work includes designing 
and implementing a totality checker for Haskell. (See the work of Vazou et al. 
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[94] for one approach toward this goal. Recent work by Karachalias et al. [51] 
is another key building block.) Unlike in other languages, though, the totality 
checker would be chiefly used in order to optimize away proofs, rather than to 
keep the language safe. Once the checker is working, we could also add compiler 
flags to give programmers compile-time warnings or errors about partial functions, 
if requested. 

• Lack of termination in functions used at the type level might conceivably cause 
GHC to loop. This is not a great concern, however, because the loop is directly 
caused by a user’s type-level program. In practice, GHC counts steps it uses in 
reducing types and reports an error after too many steps are taken. The user 
can, via a compiler flag, increase the limit or disable the check. 

The advantages to the lack of totality checking are that Dependent Haskell is 
simpler for not worrying about totality. It is also more expressive, treating partial 
functions as first-class citizens. 

3.3.4 GHC is an industrial-strength compiler 

Hosting dependent types within GHC is likely to reveal new insights about dependent 
types due to all of the features that GHC offers. Not only are there many surface 
language extensions that must be made to work with dependent types, but the back 
end must also be adapted. A dependently typed intermediate language must, for 
example, allow for optimizations. Working in the context of an industrial-strength 
compiler also forces the implementation to be more than just “research quality,” but 
ready for a broad audience. 

3.3.5 Manifest type erasure properties 

A critical property of Haskell is that it can erase types. Despite all the machinery 
available in Haskell’s type system, all type information can be dropped during compila¬ 
tion. In Dependent Haskell, this does not change. However, dependent types certainly 
blur the line between term and type, and so what, precisely, gets erased can be 
difficult to discern. Dependent Haskell, in a way different from other dependently 
typed languages, makes clear which arguments to functions (and data constructors) 
get erased. This is through the user’s choice of relevant vs. irrelevant quantifiers, as 
explored in Section 4.2.2. Because erasure properties are manifestly available in types, 
a performance-conscious user can audit a Dependent Haskell program and see exactly 
what will be removed at runtime. 

It is possible that, with practice, this ability will become burdensome, in that the 
user has to figure out what to keep and what to discard. Idris’s progress toward type 
erasure analysis [10, 90] may benefit Dependent Haskell as well. 
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3.3.6 Type-checker plugin support 

Recent versions of GHC allow type-checker plugins, a feature that allows end users to 
write a custom solver for some domain of interest. For example, Gundry [38] uses a 
plugin to solve constraints arising from using Haskell’s type system to check that a 
physical computation respects units of measure. As another example, Diatchki [22] has 
written a plugin that uses an SMT solver to work out certain numerical constraints 
that can arise using GHC’s type-level numbers feature. 

Once Haskell is equipped with dependent types, the need for these plugins will 
only increase. However, because GHC already has this accessible interface, the work of 
developing the best solvers for Dependent Haskell can be distributed over the Haskell 
community. This democratizes the development of dependently typed programs and 
spurs innovation in a way a centralized development process cannot. 

3.3.7 Haskellers want dependent types 

The design of Haskell has slowly been marching toward having dependent types. 
Haskellers have enthusiastically taken advantage of the new features. For example, over 
1,000 packages published at hackage.haskell.org use type families [86]. Anecdotally, 
Haskellers are excited about getting full dependent types, instead of just faking 
them [30, 59, 60]. Furthermore, with all of the type-level programming features that 
exist in Haskell today, it is a reasonable step to go to full dependency. 
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Chapter 4 

Dependent Haskell 


This chapter provides an overview of Dependent Haskell. I will review the new features 
of the type language (Section 4.1), introduce the small menagerie of quantifiers 
available in Dependent Haskell (Section 4.2), explain pattern matching in the presence 
of dependent types (Section 4.3), and conclude the chapter by discussing several 
further points of interest in the design of the language. 

There are many examples throughout this chapter, building on the following 
definitions: 

— Length-indexed vectors, from Section 3.1.1 
data Nat = Zero \ Succ Nat 
data Vec :: Type —>■ Nat —* Type where 

Nil :: Vec a ’ Zero 

(:>) :: a —> Vec a n ->■ Vec a (’Succ n) 

infixr 5 :> 

-- Propositional equality, from Section 2.4 

data a b where 

Refl:: a a 

— Heterogeneous lists, indexed by the list of types of elements 

data HList :: [Type] — f Type where 

HNU :: HList ’[] 

(:::) :: h —>■ HList t —> HList (/?’: t ) 

infixr 5 ::: 


4.1 Dependent Haskell is dependently typed 

The most noticeable change when going from Haskell to Dependent Haskell is that the 
latter is a full-spectrum dependently typed language. Expressions and types intermix. 
This actually is not too great a shock to the Haskell programmer, as the syntax of 
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Haskell expressions and Haskell types is so similar. However, by utterly dropping the 
distinction, Dependent Haskell has many more possibilities in types, as seen in the 
last chapter. 

No distinction between types and kinds The kind system of GHC 7.10 and 
earlier is described in Section 2.3. It maintained a distinction between types, which 
classify terms, and kinds, which classify types. Yorgey et al. [107] enriched the language 
of kinds, allowing for some types to be promoted into kinds, but it did not mix the 
two levels. 

My prior work [105] goes one step further than Yorgey et al. [107] and does merge 
types with kinds by allowing non-trivial equalities to exist among kinds. See my prior 
work for the details; this feature does not come through saliently in this dissertation, 
as I never consider any distinction between types and kinds. It is this work that is 
implemented and released in GHC 8. Removing the distinction between types and 
kinds has opened up new possibilities to the Haskell programmer. Below are brief 
examples of these new capabilities: 

• Explicit kind quantification. Previously, kind variables were all quantified implic¬ 
itly. GHC 8 allows explicit kind quantification: 

data Proxy k (a :: k) = Proxy 

— NB: Proxy takes both kind and type arguments 
f :: V k (a :: k). Proxy k a —>■ () 


• Kind-indexed GADTs. Previously, a GADT could vary the return types of 
constructors only in its type variables, never its kind variables; this restriction is 
lifted. Here is a contrived example: 

data G (a :: k) where 
MkGl ::G Int 
MkG2 :: G Maybe 


Notice that Int and Maybe have different kinds, and thus that the instantiation 
of the G’s k parameter is non-uniform between the constructors. Some recent 
prior work [75] explores applying a kind-indexed to enabling dynamic types 
within Haskell. 

• Universal promotion. As outlined by Yorgey et al. [107, Section 3.3], only some 
types were promoted to kinds in GHC 7.10 and below. In contrast, GHC 8 allows 
all types to be used in kinds. This includes type synonyms and type families, 
allowing computation in kinds for the first time. 
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• GADT constructors in types. A constructor for a GADT packs an equality 
proof, which is then exposed when the constructor is matched against. Because 
GHC 7.10 and earlier lacked informative equality proofs among kinds, GADT 
constructors could not be used in types. (They were simply not promoted.) 
However, with the rich kind equalities permitted in GHC 8, GADT constructors 
can be used freely in types, and type families may perform GADT pattern 
matching. 

Expression variables in types Dependent Haskell obviates the need for most 
closed type families by allowing the use of ordinary functions directly in types. Because 
Haskell has a separate term-level namespace from its type-level namespace, any term- 
level definition used in a type must be prefixed with a ’ mark. This expands the use 
of a ’ mark to promote constructors as initially introduced by Yorgey et al. [107]. For 
example: 

(*F) :: Nat — y Nat — y Nat 

Zero + m m 

Succ n+ m = Succ (n + m ) 

append :: Vec a n —>• Vec a m —» Vec a (n ’+ m) 

append Nil v = v 

append (h :> t) v = h :> ( append t v) 


Note that this ability does not eliminate all closed type families, as term-level function 
definitions cannot use non-linear patterns, nor can they perform unsaturated matches 
(see Section 5.1.1.2). 

Type names in terms It is sometimes necessary to go the other way and mention 
a type when writing something that syntactically appears to be a term. For the same 
reasons we need ’ when using a term-level name in a type, we use * to use a type-level 
name in a term. A case in point is the code appearing in Section 3.1.3.2. 

Pattern matching in types It is now possible to use case directly in a type: 

tailOrNil :: Vec a n —y Vec a (case n of 

’Zero —>• ’Zero 

’Succ n' —»• n ') 

tailOrNil Nil = Nil 
tailOrNil („:> t) = t 
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Anonymous functions in types Types may now include A-expressions: 


eitherize :: HList types —>• HList (’map (Aty —>• Either ty String ) types ) 

eitherize HNil = HNil 

eitherize (h ::: t) = Left h ::: eitherize t 


Other expression-level syntax in types Having merged types and expressions, 
all expression-level syntax is now available in types (for example, do-notation, let 
bindings, even arrows [46]). From a compilation standpoint, supporting these features 
is actually not a great challenge (once we have Chapters 5 and 6 implemented); it 
requires only interleaving type-checking with desugaring. 28 When a type-level use 
of elaborate expression-level syntax is encountered, we will need to work with the 
desugared version, hence the interleaving. 

4.2 Quantifiers 

Beyond simply allowing old syntax in new places, as demonstrated above, Dependent 
Haskell also introduces new quantifiers that allow users to write a broader set of 
functions than was previously possible. Before looking at the new quantifiers of 
Dependent Haskell, it is helpful to understand the several axes along which quantifiers 
can vary in the context of today’s Haskell. 

In Haskell, a quantifier is a type-level operator that introduces the type of an 
abstraction, or function. In Dependent Haskell, there are four essential properties 
of quantifiers, each of which can vary independently of the others. To understand 
the range of quantifiers that the language offers, we must go through each of these 
properties. In the text that follows, I use the term quantifiee to refer to the argument 
quantified over. The quantifier body is the type “to the right” of the quantifier. The 
quantifiers introduced in this section are summarized in Figure 4.1 on page 59. 

4.2.1 Dependency 

A quantifiee may be either dependent or non-dependent. A dependent quantifiee may 
be used in the quantifier body; a non-dependent quantifiee may not. 

Today’s Haskell uses V for dependent quantification, as follows: 

id :: V a. a —> a 

In this example, a is the quantifiee, and a —>• a is the quantifier body. Note that the 
quantifiee a is used in the quantifier body. 

28 GHC currently type-checks the Haskell source directly, allowing it to produce better error 
messages. Only after type-checking and type inference does it convert Haskell source into its internal 
language, the process called desugaring. 
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The normal function arrow (—>•) is an example of a non-dependent quantifier. 
Consider the predecessor function: 

pred :: Int Int 

The Int quantifiee is not named in the type, nor is it mentioned in the quantifier body. 

In addition to V, Dependent Haskell adds a new dependent quantifier, n. The only 
difference between n and V is that n-quantifiee is relevant, as we’ll explore next. 

4.2.2 Relevance 

A quantifiee may be either relevant or irrelevant. A relevant quantifiee may be used 
anywhere in the function quantified over; an irrelevant quantifiee may be used only in 
irrelevant positions—that is, as an irrelevant argument to other functions or in type 
annotations. Note that relevance talks about usage in the function quantified over, 
not the type quantified over (which is covered by the dependency property). 

Relevance is very closely tied to type erasure. Relevant arguments in terms are 
precisely those arguments that are not erased. However, the relevance property applies 
equally to type-level functions, where erasure does not make sense, as all types are 
erased. For gaining an intuition about relevance, thinking about type erasure is a very 
good guide. 

Today’s Haskell uses (—>•) for relevant quantification. For example, here is the body 
of pred: 

pred x = x —l 

Note that x, a relevant quantifiee, is used in a relevant position on the right-hand 
side. Relevant positions include all places in a term or type that are not within a 
type annotation, other type-level context, or irrelevant argument context, as will be 
demonstrated in the next example. 

Today’s Haskell uses V for irrelevant quantification. For example, here is the body 
of id (as given a type signature above): 

id x — (x :: a) 

The type variable a is the irrelevant quantifiee. According to Haskell’s scoped type 
variables, it is brought into scope by the V a in id's type annotation. (It could also be 
brought into scope by using a in a type annotation on the pattern x to the left of the 
=.) Although a is used in the body of id, it is used only in an irrelevant position, in 
the type annotation for x. It would violate the irrelevance of V for a to be used outside 
of a type annotation or other irrelevant context. As functions can take irrelevant 
arguments, irrelevant contexts include these irrelevant arguments. 

Dependent Haskell adds a new relevant quantifier, n. The fact that n is both 
relevant and dependent is the very reason for n’s existence! 
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4.2.3 Visibility 

A quantifiee may be either visible or invisible. The argument used to instantiate a 
visible quantifiee appears in the Haskell source; the argument used to instantiate an 
invisible quantifiee is elided. 

Today’s Haskell uses (—>•) for visible quantification. That is, when we pass an 
ordinary function an argument, the argument is visible in the Haskell source. For 
example, the 3 in pred 3 is visible. 

On the other hand, today’s V and (=^) are invisible quantifiers. When we call 
id True, the a in the type of id is instantiated at Bool, but Bool is elided in the call 
id True. During type inference, GHC uses unification to discover that the correct 
argument to use for a is Bool. 

Invisible arguments specified with (=>) are constraints. Take, for example, show :: 
V a. Show a =>• a —>• String. The show function properly takes 3 arguments: the 
V-quantified type variable a, the (=>)-quantified dictionary for Show a (see Section 2.1 
if this statement surprises you), and the (—^-quantified argument of type a. However, 
we use show as, say, show True, passing only one argument visibly. The V a argument 
is discovered by unification to be Bool, but the Show a argument is discovered using 
a different mechanism: instance solving and lookup. (See the work of Vytiniotis et al. 
[99] for the algorithm used.) We thus must be aware that invisible arguments may use 
different mechanisms for instantiation. 

Dependent Haskell offers both visible and invisible forms of V and n; the invisible 
forms instantiate only via unification. Dependent Haskell retains, of course, the invisible 
quantifier (=>), which is instantiated via instance lookup and solving. Finally, note 
that visibility is a quality only of source Haskell. All arguments are always “visible” in 
Pico. 

It may be helpful to compare Dependent Haskell’s treatment of visibility to that 
in other languages; see Section 8.6. 

4.2.3.1 Visibility overrides 

It is often desirable when using rich types to override a declared visibility specification. 
That is, when a function is declared to have an invisible parameter a, a call site may 
wish to instantiate a visibly. Conversely, a function may declare a visible parameter 
b, but a caller knows that the choice for b can be discovered by unification and so 
wishes to omit it at the call site. 

Instantiating invisible parameters visibly Dependent Haskell adopts the @... 
syntax of Eisenberg et al. [33] to instantiate any invisible parameter visibly, whether 
it is a type or not. Continuing our example with id, we could write id @Bool True 
instead of id True. This syntax works in patterns, expressions, and types. In patterns, 
the choice of @ conflicts with as-patterns, such as using the pattern list@(x: xs) to bind 
list to the whole list while pattern matching. However, as-patterns are almost always 
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written without whitespace. I thus use the presence of whitespace before the @ to 
signal the choice between an as-pattern and a visibility override. 29 Dictionaries cannot 
be named in Haskell, so this visibility override skips over any constraint arguments. 

Omitting visible parameters The function replicate :: n (n:: Nat ) —>• a —> Vec a n 
from Section 3.1.1.3 creates a length-indexed vector of length n, where n is passed 
in as the first visible argument. (The true first argument is a, which is invisible and 
elided from the type.) However, the choice for n can be inferred from the context. For 
example: 

theSimons :: Vec String 2 

theSimons = replicate 2 "Simon" 


In this case, the two uses of 2 are redundant. We know from the type signature that 
the length of theSimons should be 2. So we can omit the visible parameter n when 
calling replicate: 

theSimons ’:: Vec String 2 
theSimons' = replicate _ "Simon" 


The underscore tells GHC to infer the missing parameter via unification. 

The two overrides can usefully be combined, when we wish to infer the instantiation 
of some invisible parameters but then specify the value for some later invisible 
parameter. Consider, for example, coerce :: V a b. Coercible a b => a —> b. In the call 
coerce (MkAge 3) (where we have newtype Age = MkAge Int ), we can infer the value 
for a, but the choice for b is a mystery. We can thus say coerce @lnt (MkAge 3), 
which will convert MkAge 3 to an Int. 

The choice of syntax for omitting visible parameters conflicts somewhat with the 
feature of typed holes , whereby a programmer can leave out a part of an expression, 
replacing it with an underscore, and then get an informative error message about the 
type of expression expected at that point in the program. (This is not unlike Agda’s 
sheds feature or Idris’s metavariables feature.) However, this is not a true conflict, as 
an uninferrable omitted visible parameter is indeed an error and should be reported; 
the error report is that of a typed hole. Depending on user feedback, this override of 
the underscore symbol may be hidden behind a language extension or other compiler 
flag. 

29 This perhaps-surprising decision based on whitespace is regrettable, but it has company. The 
symbol $ can mean an ordinary, user-defined operator when it is followed by a space but a Template 
Haskell splice when there is no space. The symbol . can mean an ordinary, user-defined operator 
when it is preceded by a space but indicate namespace resolution when it is not. Introducing these 
oddities seems a good bargain for concision in the final language. 
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4.2.4 Matchability 

Suppose we know that f a equals g b. What relationship can we conclude about 
the individual pieces? In general, nothing: there is no way to reduce f a ~ g b for 
arbitrary f and g. Yet Haskell type inference must simplify such equations frequently. 
For example: 

class Monad m where 
return :: a —>• m a 

just5 :: Maybe Int 
just5 = return 5 

When calling return in the body of just5, type inference must determine how to 
instantiate the call to return. We can see that m a (the return type of return) must be 
Maybe Int. We surely want type inference to decide to set m to Maybe and a to Inti 
Otherwise, much current Haskell code would no longer compile. 

The reason it is sensible to reduce m a ~ Maybe Int to m ~ Maybe and a ~ Int 
is that all type constructors in Haskell are generative and injective, according to these 
definitions: 

Definition (Generativity). If f and g are generative, then fa~gb implies f ~ g . 30 

Definition (Injectivity). If f is injective, then fa ~ fb implies a ~ b. 

Because these two notions go together so often in the context of Haskell, I introduce 
a new word matchable, thus: 

Definition (Matchability). A function f is matchable iff it is generative and injective. 

Thus, we say that all type constructors in Haskell are matchable. Note that if f 
and g are matchable, then f a ~ g b implies f ~ g and a ~ b, as desired. 

On the other hand, ordinary Haskell functions are not, in general, matchable. 
The inability to reduce f a ~ g b to f ~ g and a ~ b for arbitrary functions is 
precisely why type families must be saturated in today’s Haskell. If they were allowed 
to appear unsaturated, then the type inference algorithm could no longer assume that 
higher-kinded types are always matchable, 31 and inference would grind to a halt. 

The solution is to separate out matchable functions from unmatchable ones, 
classifying each by their own quantifier, as described in my prior work [29], 

The difference already exists in today’s Haskell between a matchable arrow and an 
unmatchable arrow, though this difference is invisible. When we write an arrow in a 

30 As we see in this definition, generativity is really a relation between pairs of types. We can 
consider the type constructors to be a set such that any pair are generative w.r.t. the other. When I 
talk about a type being generative, it is in relation to this set. 

31 For example, unifying a b with Maybe Int would no longer have a unique solution. 
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Quantifier 

Dependency 

Relevance 

Visibility 

Matchability 

V (a :: r). ... 

dep. 

irrel. 

inv. (unification) 

unmatchable 

V (a :: t). ... 

dep. 

irrel. 

inv. (unification) 

matchable 

V (a :: r) —» ... 

dep. 

irrel. 

vis. 

unmatchable 

V (a :: r) —>• ... 

dep. 

irrel. 

vis. 

matchable 

n (a::r). ... 

dep. 

rel. 

inv. (unification) 

unmatchable 

’ n (a::r). ... 

dep. 

rel. 

inv. (unification) 

matchable 

n (a :: r) ... 

dep. 

rel. 

vis. 

unmatchable 

’n (a :: r) —> ... 

dep. 

rel. 

vis. 

matchable 

T => ... 

non-dep. 

rel. 

inv. (solving) 

unmatchable 

T ’=> ... 

non-dep. 

rel. 

inv. (solving) 

matchable 

T ... 

non-dep. 

rel. 

vis. 

unmatchable 

T ... 

non-dep. 

rel. 

vis. 

matchable 


Figure 4.1: The twelve quantifiers of Dependent Haskell 


type that classifies an expression, that arrow is unmatchable. But when we write an 
arrow in a kind that classifies a type, the arrow is matchable. This is why map :: (a —» 
b ) —>• [a] —>• [6] does not cleanly promote to the type Map :: (a —>• 6) —>• [a] —>• [6]; if 
you write that type family, it is much more restrictive than the term-level function. 

The idea of matchability also helps to explain why, so far, we have been able only 
to promote data constructors into types: data constructors are matchable—this is why 
pattern matching on constructors makes any sense at all. When we promote a data 
constructor to a type constructor, the constructor’s matchable nature fits well with 
the fact that all type constructors are matchable. 

Dependent Haskell thus introduces a new arrow, spelled >, that classifies match- 
able functions. The idea is that ’ is used to promote data constructors, and > promotes 
the arrow used in data constructor types. In order to be backward compatible, types 
of type constructors (as in data Vec :: Type —>• Nat —> Type) and types of data 
constructors (as in Just:: a —>• Maybe a) can still be written with an ordinary arrow, 
even though those arrows should properly be ’—K Along similar fines, any arrow written 
in a stretch of Haskell that is lexically a kind (that is, in a type signature in a type) is 
interpreted as > as long as the DependentTypes extension is not enabled. 

We can now say ’map :: (a —>• b) —> [a] —» [ b ], with unmatchable — y, and retain 
the flexibility we have in the expression map. 

4.2.5 The twelve quantifiers of Dependent Haskell 

Now that we have enumerated the quantifier properties, we are ready to describe the 
twelve quantifiers that exist in Dependent Haskell. They appear in Figure 4.1. The 
first one (V (a:: t). ...) and two near the bottom (=>• and —Q exist in today’s Haskell 
and are completely unchanged. Dependent Haskell adds a visible V, the n quantifiers, 
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and matchable versions of everything. 32 

It is expected that the matchable quantifiers will be a rarity in user code. These 
quantifiers are used to describe type and data constructors, but matchability is assumed 
in a type or data constructor signature. Beyond those signatures, I don’t imagine 
many users will need to write matchable function types. However, there is no reason 
to prevent users from writing these, so I have included them in the user-facing design. 

The visible V is useful in situations where a type parameter might otherwise be 
ambiguous. For example, suppose F is a non-injective [86] type family and consider 
this: 


frob :: V a. F a —F [a] 

This type signature is inherently ambiguous—we cannot know the choice of a even 
if we know we want a such that frob :: Int —> Bool —and GHC reports an error when 
it is written. Suppose that we know we want a particular use of frob to have type 
Int —>• Bool. Even with that knowledge, there is no way to determine how to instantiate 
a. To fix this problem, we simply make a visible: 

frob :: V a -»■ F a -)• F [a] 


Now, any call to frob must specify the choice for a, and the type is no longer ambiguous. 

A n-quantified parameter is both dependent (it can be used in types) and relevant 
(it can be used in terms). Critically, pattern-matching (in a term) on a n-quantified 
parameter informs our knowledge about that parameter as it is used in types, a subject 
we explore in the next section. 

Lastly, Dependent Haskell omits the non-dependent, irrelevant quantifiers, as a 
non-dependent, irrelevant quantifiee would not be able to be used anywhere. 

4.3 Pattern matching 

We will approach an understanding of pattern matches in stages, working through three 
examples of increasing complexity. All these examples will work over the somewhat 
hackneyed length-indexed vectors for simplicity and familiarity. 

32 The choice of syntax here is directly due to the work of Gundry [37]. 
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4.3.1 A simple pattern match 

Naturally, Dependent Haskell retains the capability for simple pattern matches: 

— isEmpty :: Vec a n —> Bool 
isEmpty v = case 1/ of 
Nil True 
„ -A False 

A simple pattern match looks at a scrutinee —in this case, v —and chooses a case 
alternative depending on the value of the scrutinee. The bodies of the case alternatives 
need no extra information to be well typed. In this case, every body is clearly a Bool, 
with no dependency on which case has been chosen. Indeed, swapping the bodies 
would yield a well typed pattern match, too. In a simple pattern match, no type 
signature is required. 33 

4.3.2 A GADT pattern match 

Today’s Haskell (and Dependent Haskell) supports GADT pattern-matches, where 
learning about the constructor that forms a scrutinee’s value can affect the types in a 
case alternative body. Here is the example: 

pred :: Nat —> Nat 

pred Zero = error "pred Zero" 

pred (Succ n) = n 

safeTail:: Vec a n —> Either ( n :~: ’Zero) (Vec a (’ pred n )) 
safeTail Nil = Left Refl 
safeTail (_ :> t ) = Right t 


In this example, we must use type information learned through the pattern match in 
order for the body of the pattern match to type-check. (Here, and in the last example, I 
use the more typical syntax of defining a function via pattern matching. The reasoning 
is the same as if I had used an explicit case.) Let’s examine the two pattern match 
bodies individually: 

• For Left Refl to be well typed at Either (n :~: ’Zero) r, we need to know that n 
is indeed 'Zero. This fact is known only because we have pattern-matched on 
Nil. Note that the type of Nil is Vec a 'Zero. Because we have discovered that 
our argument of type Vec an is Nil :: Vec a 'Zero, it must be that n ~ ’Zero, as 
desired. 

33 Expert readers may be puzzled why this example is accepted without a type signature. After all, 
pattern-matching against Nil indeed does introduce a type equality, making the result type of the 
match hard to infer. In this case, however, the existence of the last pattern, which introduces no 
equalities, allows the return type to be inferred as Bool. 
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• For Right t to be well typed at Either r (Vec a ( 'pred n )) (where t :: Vec an' for 
some n'), we need to know that n ~ ’Succ n', so that we can simplify ’ pred n 
to ’pred (’Succ n') to n '. The equality n ~ ’Succ n' is exactly what we get by 
pattern-matching on :>. 

Note that I have provided a type signature for safeTail. This is necessary in the event 
of a GADT pattern match, because there is no way, in general, to infer the return 
type of a pattern match where each branch has a type equality in scope. 34 

4.3.3 Dependent pattern match 

New to Dependent Haskell is the dependent pattern match, shown here: 

replicate ::U n —> a —> Vec a n 

replicate Zero _ = Nil 

replicate (Succ n') x = x :> replicate n' x 


Let’s again consider the function bodies one at a time: 

• Its type signature tells us Nil has type Vec a ’Zero . Thus for Nil to be well typed 
in replicate, we must know that n ~ ’Zero. We indeed do know this, as we have 
scrutinized n and found that n is ’Zero. 

• For the recursive call to be well typed, we need to know that n ~ ’Succ n', 
which is, once again, what we know by the pattern match. 

Note the difference between this case of dependent pattern match and the previous 
case of GADT pattern match. In GADT pattern matching, the equality assumption 
of interest is found by looking at the type of the constructor that we have found. In a 
dependent pattern match, on the other hand, the equality assumption of interest is 
between the scrutinee and the constructor. In our case here, the scrutinized value is 
not even of a GADT; Nat is a perfectly ordinary, Haskell98 datatype. 

A question naturally comes up in this example: when should we do dependent 
pattern match and when should we do a traditional (non-dependent) pattern match? 
A naive answer might be to always do dependent pattern matching, as we can always 
feel free to ignore the extra, unused equality if we do not need it. However, this would 
not work in practice—with an equality assumption in scope, we cannot accurately infer 
the return type of a pattern match. Yet this last problem delivers us the solution: use 
dependent pattern matching only when we know a match’s result type, as propagated 
down via a bidirectional type system. (This is much the same way that today’s Haskell 
allows inference in the presence of higher-rank types [74], See Section 6.4 for the 

34 If this last statement is a surprise to you, the introduction of Vytiniotis et al. [99] has a nice 
explanation of why this is a hard problem. 
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details.) If we know a result type and do not need the dependent pattern match 
equality, no harm is done. On the other hand, if we do not know the result type, this 
design decision means that dependent pattern matching does not get in the way of 
inferring the types of Haskell98 programs. 


4.4 Discussion 

The larger syntactic changes to Haskell as it becomes Dependent Haskell are sketched 
above. In addition to these changes, Haskell’s typing rules naturally become much 
more involved. Though a declarative specification remains out of reach, Chapter 6 
describes (and Appendix D details) the algorithm Bake, which is used to detect 
type-correct Dependent Haskell programs. It is important future work to develop a 
more declarative specification of Dependent Haskell. 

This section comments on several topics that affect the design of Dependent Haskell. 

4.4.1 Type : Type 

Dependent Haskell includes the Type : Type axiom, avoiding the infinite hierarchy of 
sorts [57, 80] that appear in other dependently-typed languages. This choice is made 
solely to simplify the language. Other languages avoid the Type : Type axiom in 
order to remain consistent as a logic. However, to have logical consistency, a language 
must be total. Haskell already has many sources of partiality, so there is little risk in 
adding one more. 

Despite the questionable reputation of the Type : Type axiom, languages with 
this feature have been proved type-safe for some time. Cardelli [12] gives a thorough 
early history of the axiom and presents a type-safe language with Type : Type. Given 
the inherent partiality of Haskell, the inclusion of this axiom has little effect on the 
theory. 

4.4.2 Inferring II 

The discussion of quantifiers in this chapter begs a question: which quantifier is chosen 
when the user has not written any? The answer: —>. Despite all of the advances to 
the type system that come with Dependent Haskell, the non-dependent, relevant, 
visible, and unmatchable function type, —>■, remains the bedrock. In absence of other 
information, this is the quantifier that will be used. 

However, as determined by the type inference process (Chapter 6), an inferred 
type might still have a n in it. For example, if I declare 

replicate' = replicate 

without giving a type signature to replicate', it should naturally get the same type 
(which includes a n) as replicate. Indeed this is what is delivered by Bake, Dependent 
Haskell’s type inference algorithm. 
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On the other hand, the generalized type of the expression A f g x ^ f (g x) 
is V a 6 c. (/?—>• c) —> (a —> h) —> (a -4 c), the traditional type for function 
composition, not the much more elaborate type (see Section 6.1) for a dependently 
typed composition function. The more exotic types are introduced only when written 
in by the user. 

4.4.3 Roles and dependent types 

Integrating dependent types with Haskell’s role mechanism [11] is a challenge, as 
explored in some depth in my prior, unpublished work [27]. Instead of addressing this 
issue head-on, I am deferring the resolution until we can find a better solution than 
what was proposed in that prior work. That approach, unworthy of being repeated here, 
is far too ornate and hard to predict. Instead, I make a simplifying assumption that 
all coercions used in types have a nominal role. 35 This choice restricts the way Haskell 
newtypes can work with dependent types if the coerce function has been used. A 
violation of this restriction (yet to be nailed down, exactly) can be detected after type¬ 
checking and does not affect the larger type system. It is my hope that, once the rest of 
Dependent Haskell is implemented, a solution to this thorny problem will present itself. 
A leading, unexplored candidate is to have two types of casts: representational and 
nominal. Currently, all casts are representational; possibly, tracking representational 
casts separately from nominal casts will allow a smoother integration of roles and 
dependent types than does the ornate approach in my prior work. 

4.4.4 Impredicativity, or lack thereof 

Despite a published paper [97] and continued attempts at cracking this nut, GHC lacks 
support for impredicativity. 36 Here, I use the following definitions in my meaning of 
impredicativity, which has admittedly drifted somewhat from its philosophical origins: 

Definition (Simple types). A simple type has no constraint, quantification, or de¬ 
pendency. 

Definition (Impredicativity). A program is impredicative if it requires a non-simple 
type to be substituted for a type variable. 

Impredicativity is challenging to implement while retaining predictable type infer¬ 
ence, essentially because it is impossible to know where to infer invisible arguments— 
invisible arguments can be hidden behind a type variable in an impredicative type 
system. 

Dependent Haskell does not change this state of affairs in any way. In Dependent 
Haskell, just like in today’s Haskell, impredicativity is simply not allowed. 

35 If you are not familiar with roles, do not fret. Instead, safely skip the rest of this subsection. 
36 There does exist an extension ImpredicativeTypes. However, it is unmaintained, deprecated, 
and quite broken. 
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There is a tantalizing future direction here, however: are the restrictions around 
impredicativity due to invisible binders only? Perhaps. Up until now, it has been 
impossible to have a dependent or irrelevant binder without that binder also being 
invisible. (To wit, V is the invisible, dependent, irrelevant binder of today’s Haskell.) 
One of the tasks of enhancing Haskell with dependent types is picking apart the 
relationship among all of the qualities of quantifiers [56]. It is conceivable that the 
reason impredicativity hinders the predictability of type inference has to do only 
with visibility, allowing arbitrary instantiations of type variables with complex types, 
as long as they have no invisible binders. Such an idea requires close study before 
implementing, but by pursuing this idea, we may be able to relax the impredicativity 
restriction substantially. 

4.4.5 Running proofs 

Haskell is a partial language. It has a multitude of ways of introducing a computa¬ 
tion that does not reduce to a value: T/error, general recursion, incomplete pattern 
matches, non-strictly-positive datatypes, baked-in type representations [75], and possi¬ 
bly Girard’s paradox [36, 48], among others. This is in sharp contrast to many other 
dependently typed language, which are total. (An important exception is Cayenne. 
See Section 8.3.) 

In a total language, if you have a function pf that results in a proof that a ~ b, 
you never need to run the function. (Here, I’m ignoring the possibility of multiple, 
different proofs of equality [91].) By the totality of that language, you are assured 
that pf will always terminate, and thus running pf yields no information. 

On the other hand, in a partial language like Haskell, it is always possible that pf 
diverges or errors. We are thus required to run pf to make sure that it terminates. 
This is disappointing, as the only point of running pf is to prove a type equality, and 
types are supposed to be erased. However, the Haskell function pf has two possible 
outcomes: an uninformative (at runtime) proof of type equality, or divergence. There 
seems to be no easy, sound way around this restriction, which will unfortunately have 
a real effect on the runtimes of dependently typed Haskell programs. 37 

Despite not having an easy, sound workaround, GHC already comes with an easy, 
tmsound workaround: rewrite rules [73]. A rewrite rule (written with a RULES pragma) 
instructs GHC to exchange one fragment of a program in its intermediate language 
with another, by pattern matching on the program structure. For example, a user can 
write a rule to change map id to id. To the case in point, a user could write a rule 
that changes pf... to unsafeCoerce Reft. Such a rule would eliminate the possibility of 
a runtime cost to the proof. By writing this rule, the user is effectively asserting that 
the proof always terminates. 

37 Note that running a term like pf is the only negative consequence of Haskell’s partiality. If, say, 
Agda always ran its proofs, it could be partial, too! This loses logical consistency—and may surprise 
users expecting something that looks like a proof to actually be a proof—but the language would 
remain type safe. 
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4.4.6 Import and export lists 

Recall the safeTail example from Section 4.3.2. As discussed in that section, for safeTail 
to compile, it is necessary to reduce ’pred ( Succ n ') to n'. This reduction requires 
knowledge of the details of the implementation of pred. However, if we imagine that 
pred is defined in another module, it is conceivable that the author of pred wishes to 
keep the precise implementation of pred private—after all, it might change in future 
versions of the module. Naturally, hiding the implementation of pred would prevent 
an importing module from writing safeTail, but that should be the library author’s 
prerogative. 

Another way of examining this problem is to recognize that the definition of pred 
encompasses two distinct pieces of information: pred’s type and pred 1 s body. A module 
author should have the option of exporting the type without the body. 

This finer control is done by a small generalization of the syntax in import and 
export lists. If a user includes pred in an import/export list, only the name pred and 
its type are involved. On the other hand, writing pred(..) (with a literal (..) in the 
source code) in the import/export list also includes pred’s implementation. This echoes 
the current syntax of using, say, Bool to export only the Bool symbol while Bool (..) 
exports Bool with all of its constructors. 

4.4.7 Type-checking is undecidable 

In order to type-check a Dependent Haskell program, it is sometimes necesary to eval¬ 
uate expressions used in types. Of course, these expressions might be non-terminating 
in Haskell. Accordingly, type-checking Dependent Haskell is undecidable. 

This fact, however, is not worrisome. Indeed, GHC’s type-checker has had the 
potential to loop for some time. Assuming that the solver’s own algorithm terminates, 
type-checking will loop only when the user has written a type-level program that loops. 
Programmers are not surprised when they write an ordinary term-level program that 
loops at runtime; they should be similarly not surprised when they write a type-level 
program that loops at compile time. In order to provide a better user experience, 
GHC counts reduction steps and halts with an error message if the count gets too 
high; users can disable this check or increase the limit via a compiler flag. 

4.5 Conclusion 

This chapter has offered a concrete description of Dependent Haskell. Other than 
around the addition of new quantifiers, most of the changes are loosening of restrictions 
that exist in today’s Haskell. (For example, a ’ mark in a type today can promote only 
a constructor; Dependent Haskell allows any identifier to be so promoted.) Accordingly, 
and in concert with the conservativity of the type inference algorithm (Sections 6.8.2 
and 6.8.3), programs that compile today will continue to do so under Dependent 
Haskell. 
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Naturally, what is described here is just my own considered vision for Dependent 
Haskell. I am looking forward to the process of getting feedback from the Haskell 
community and evolving this description of the language to fit the community’s needs. 
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Chapter 5 

PICO: The intermediate language 


This chapter presents PlCO, the internal language that Dependent Haskell compiles 
into. I have proved type safety (via the usual preservation and progress theorems, 
Theorem C.46 and Theorem C.78) and type erasure (Theorem C.83 and Theorem 
C.86). I believe PlCO would make a strong candidate for the internal language in a 
future version of GHC. 

5.1 Overview 

PlCO (pronounced “n-co”, never “peek-o”) descends directly from the long line of work 
on System FC [87]. It is most closely related to the version of System FC presented in 
my prior work [105] and in Gundry’s thesis [37]. 

PlCO sits in the A-cube [6] on the same vertex as the Calculus of Constructions [19], 
but with a very different notion of equality. A typical dependently typed calculus 
contains a conversion rule, something like this: 

r : K 1 Ki = k 2 

- CONV 

t : k 2 

This rule encapsulates the point of type equivalence: if a type r is found to have some 
kind K\ and K\ is known to be equivalent to some tc 2 , then we can say that t has 
kind tc 2 . 38 This rule is flexible and helps a language to be succinct. It has a major 
drawback, however: it is not syntax directed. In general, determining whether «q = k 2 
might not be easy. Indeed, type equivalence in PlCO is undecidable, so we would 
have a hard time building a type-checker with a CONV rule such as this one. Other 
dependently typed languages are forced to restrict expressiveness in order to keep 

38 I tend to use the word “kind” when referring to the classification of a type. However, in the 
languages considered in this dissertation, kinds and types come from the same grammar; the terms 
“type” and “kind” are technically equivalent. Nevertheless, I find that discerning between these two 
words can aid intuition and will continue to do so throughout the dissertation. 
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type-checking decidable; this need for decidable type equivalence is one motivation to 
design a dependently typed language to be strongly normalizing. 

Pico’s approach to type equivalence (and the CONV rule) derives from the coercions 
that provide the “C” in “System FC”. Instead of relying on a non-syntax-directed 
equivalence relation, Pico’s type equivalence requires evidence of equality in the form 
of coercions. Here is a simplified version of Pico’s take on the CONV rule: 


r : k i 7 : Ki ~ k 2 

t > 7 : k 2 


Ty_Cast 


In this rule, the metavariable 7 stands for a coercion, a proof of the equality between 
two types. Here, we see that 7 proves that kinds K\ and k 2 are equivalent. Thus, we 
can type r > 7 at k 2 as long as r can be typed at K\. Note the critical appearance of 
7 in the conclusion of the rule: this rule is syntax-directed. The type-checker simply 
needs to check the equality proofs against a set of (also syntax-directed) rules, not to 
check some more general equivalence relation. 

The grammar for coercions (in Figure 5.1 on page 76) allows for a wide variety 
of coercion forms, giving PlCO a powerful notion of type equivalence. However, 
coercions have no notion of evaluation nor proper A-abstractions . 39 Thus, the fact 
that evaluation in PlCO might not terminate does not threaten the type safety of 
the language. Coercions are held separate from types, and proving consistency of the 
coercion language (Section 5.10)—ill other words, that we cannot prove Int ~ Bool —is 
the heart of the type safety proof. It does not, naturally, depend on any termination 
proof, nor any termination checking of the program being checked. The independence 
of Pico’s type safety result from termination means that PlCO can avoid many 
potential traps that have snagged other dependently typed languages that rely on 
intricate termination checks . 40 


5.1.1 Features of PlCO 

PlCO is a dependently typed A-calculus with mutually recursive algebraic datatypes 
and a fixpoint operator. Recursion is modeled only via this fixpoint operator; there is 
no recursive let. Other than the way in which the operational semantics deals with 
coercions in the form of push rules, the small-step semantics is what you might expect 
for a call-by-name A-calculus. 

The typing relations, however, have a few features worth mentioning up front 
(other unusual features are best explained after the detailed coverage of PlCO; see 
Section 5.12). 

39 There is a coercion form that starts with A; it is only a congruence form for A-abstractions in 
types, not a A-abstraction in the coercion language. See Section 5.8.5.1. 

40 For example, see https://coq.inria.fr/cocorico/CoqTerminationDiscussion. 
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5.1.1.1 Relevance annotations and type erasure 

A key concern when compiling a dependently typed language is type erasure. Given 
that terms and types can intermingle, what should be erased during compilation? 
And what data is necessary to be retained until runtime? Dependent Haskell (and, in 
turn, Pico) forces the user to specify this detail at each quantifier (Section 5.3). In 

the formal grammar of PlCO, we distinguish between no:R e |K.... and na:i rre |K.The 

former is the type of an abstraction that is retained at runtime, written with a n in 
Haskell; the latter, written with V, is fully erased. In order to back up this claim of full 
erasure of irrelevant quantification, evaluation happens under irrelevant abstractions; 
see Section 5.7.1. 

So that we can be sure a variable’s relevance is respected at use sites, variable 
contexts T track the relevance of bound variables. Only relevant variables may appear 
in the “level” in which they were bound; when a typing premise refers to a higher 
“level”, the context is altered to mark all variables as relevant. For example, the case 
construct case K t of alt includes the return kind of the entire case expression as its k 
subscript. This kind is type-checked in a context where all variables are marked as 
relevant; because the kind is erased during compilation, the use of an irrelevant variable 
there is allowed. As they are also erased, coercions are considered fully irrelevant as 
well. 

My treatment of resetting the context is precisely like what is done by Mishra-Linger 
and Sheard [65]. 

5.1.1.2 Tracking matchable vs. unmatchable functions 

Dependent Haskell supports both matchable—that is, generative and injective— 
abstractions and unmatchable ones (Section 4.2.4). Though at first it might appear 
that separating out these two modalities is necessary only to support type inference, 
PlCO maintains this distinction. Every n-type in PlCO is labeled as either matchable 
or unmatchable: TI denotes a matchable n-type and II denotes an unmatchable one. 
An unadorned n is a metavariable which might be instantiated either to H or IT We 
do not have to label A-abstractions, however, because all A-abstractions are always 
unmatchable—only partially applied type constants (or functions returning them) are 
matchable. 

PlCO maintains the matchable/unmatchable distinction for two reasons: 

Decomposing coercions over function applications Since at least the invention 
of System FC [87], GHC has supported application decomposition. That is, from a 
proof that n o\ equals r 2 cr 2 , we can derive proofs of T\ ~ r 2 and o\ ~ <r 2 . I would like 
to retain this ability in PlCO in order to support the claim that Dependent Haskell is 
a conservative extension over today’s Haskell. However, decomposing an application 
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as above in the presence of unsaturated A-abstractions is clearly bogus. 41 

The solution here is to keep matchable applications separate from unmatchable 
ones, and allow decomposition only of matchable applications. The two application 
forms comprise different nodes in the PlCO grammar. Decomposing only matchable 
applications is a backward-compatible treatment, as today’s Haskell has only matchable 
applications. In turn, keeping the application forms separate requires tracking the 
matchability of the abstractions themselves. 

Pico’s support of the application decomposition while allowing unsaturated A- 
abstractions is one of the key improvements PlCO makes over Gundry’s evidence 
language [37]. See Section 8.1 for more discussion of the comparison of my work to 
Gundry’s. 

Matching on partially applied constants PlCO does not contain type families. 
Instead, it uses A-abstractions and case expressions, as these are more familiar to 
functional programmers. And yet, I wish for PlCO to support the variety of ways in 
which type families are used in today’s Haskell. One curiosity of today’s Haskell is 
that it allows matching on partially applied data constructors: 

type family IsLeft a where 
IsLeft ’Left = ’True 
IsLeft ’Right = ’False 

The type family IsLeft is inferred to have kind V k. (k —>• Either k k) —>• Bool. (Note 
that k —>• Either k k is what you get when unifying the kind of Left with that of Right.) 
That is, it matches on the Left and Right constructors, even though these are not 
applied to arguments. While it may seem that IsLeft is matching on a function —after 
all, the type of IsLeft' 1 s argument appears to be an arrow type—it is not. It is matching 
only on constructors, because today’s kind-level —>• classifies only type constants. That 
is, it really should be spelled ’—K 

To support functions such as IsLeft, PlCO allows case scrutinees to have matchable 
Tl-types, instead of just fully applied datatypes. As designed here, matching on partially 
applied data constructors is also available at the term level in PlCO. However, practical 
considerations (e.g., how would you compile such a match?) may lead us to prevent 
the use of this feature from surface Haskell. 

5.1.1.3 Matching on Type 

Today’s Haskell also has the ability, through its type families, to match on members 
of Type. For example: 

41 For example, we can prove (Xx:R e \lnt. 3) 4 ~ (Xx:R e \lnt. 3) 5 but do not wish to be able to prove 
4 ~ 5. 
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type family IntLike x where 
IntLike Integer = ’True 
IntLike Int = ’True 
IntLike _ = ’Fa/se 

This ability for a function to inspect the choice of a type—and not a code for a 
type—is unique among production languages to Haskell, as far as I am aware. With 
the type families in today’s Haskell, discerning between types is done by simple pattern 
matching. However, if we compile type families to case statements, we need a way to 
deal with this construct, even though Type is not an algebraic datatype. 

Fortunately, types like Either resemble data constructors like Just: both are classified 
by matchable quantification(s) over a type headed by another type constant. In the case 
of Either , we have Either : Tl_:R e |Type, _:R e |Type. Type; 42 note that the body of the 
n-type is headed by the constant Type. For Just, we have Just{ a } : ’n_:R e ia. Maybe a. 43 
With this similarity, it is not hard to create a typing rule for a case statement that 
can handle both data constructors (like Just ) and types (like Either). 

A key feature, however, that is needed to support matching on Type is default 
patterns. For a closed datatype, where all the constructors can be enumerated, default 
patterns are merely a convenience; any default can be expanded to list all possible 
constructors. For an open type, like Type, the availability of the default pattern is 
essential. It is for this reason alone that I have chosen to include default patterns in 
Pico. 

5.1.1.4 Hypothetical equality 

PlCO allows abstraction over coercions, much like any A-calculus allows abstraction 
over expressions (or, in a call-by-value calculus, values). Coercion abstraction means 
that a type equality may be assumed in a given type. When we wish to evaluate a 
term that assumes an equality, we must apply that term to evidence that the equality 
holds—an actual coercion. It is this ability, to assume an equality, that allows PlCO 
to have GADTs. See the example in Section 5.5 for the details. 

5.1.2 Design requirements for PlCO 

In the course of any language design, there needs to be a guiding principle to aid in 
making free design decisions. The chief motivator for the design of PlCO is that it 
should be suitable for use as the internal language of a Haskell compiler. This use case 
provides several desiderata: 

Decidable, syntax-directed, efficient type checking The use of types in a 
compiler’s intermediate language serves only as a check of the correctness of the 

42 Why Rel? See the end of Section 5.4.2.2. 

43 The {a} subscript is explained in Section 5.4.1. 
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compiler. Any programmer errors are caught before the intermediate language code 
is emitted, and so a correct compiler should only produce well typed intermediate- 
language programs, if it produces such programs at all. In addition, a correct compiler 
performing program transformations on the intermediate language should take a well 
typed program to a well typed program. However, not all compilers are correct, and 
thus it is helpful to have a way to check that intermediate-language program generation 
and transformation is at least type-preserving. To check this property, we need to 
type-check the intermediate language, both after it is originally produced and after 
every transformation. It thus must be easy and efficient to do so. 

PlCO essentially encodes a typing derivation right in the syntax of types and 
coercions. It is thus very easy to write a type checker for the language. Type-checking 
is manifestly decidable and can be done in one pass over the program text, with no 
constraint solving . 44 Pico’s lack of a termination requirement also significantly lowers 
the burden of implementation of a type checker for the language. 

Erasability An intermediate-language program should make clear what information 
can be erased at runtime. After all, when the compiler is done performing optimizations, 
runtime code generation must take place, and we thus need to know what information 
can be dropped. It is for this reason that PlCO includes the relevance annotations. 

A balance between ease of proving and ease of implementation PlCO serves 
two goals: to be a template for an implementation, and also to be a calculus used to 
prove type safety. These goals are sometimes at odds with each other. 

These two goals of System FC have tugged in different directions since the advent 
of FC. Historically, published versions of the language have greatly simplified certain 
details. No previously published treatment of FC has included support for recursion, 
either through letrec or fix. In contrast, the implemented version of FC (also called 
GHC Core) makes certain choices for efficiency; for example, applied type constructors, 
such as Either Int Bool , have a different representation than do applied type variables, 
such as a Int Bool. The former is stored as the head constructor with a list of 
arguments, and the latter is stored as nested binary applications. This is convenient 
when implementing but meddlesome when proving properties. The divergence between 
published FC and the implemented version (more often called GHC Core) have led to 
a separate document just to track the implemented version [26]. 

In the design of PlCO, I have aimed for balance between these two needs. Because 
of the risk that non-termination might cause unsoundness, I have explicitly included 
fix in the design, just to make sure that the non-termination is obvious. 45 I have 

44 I do not claim that it is strictly linear, as a formal analysis of its running time is beyond the 
scope of this dissertation. In particular, one rule (see Section 5.6.5) requires the use of a unification 
algorithm and likely breaks linearity. 

45 With Type : Type, we have the possibility of Girard’s paradox [36, 48] and thus can have 
non-termination even without fix, but making the non-termination more obvious clarifies that we 
can achieve type safety without termination. 
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not, however, included an explicit let or letrec construct, as the specification of 
these would be quite involved, and yet desugaring these constructs into A and fix is 
straightforward. (See Section 5.13.1.) 

On the other hand, I have included case. Having case in the language also 
significantly complicates the presentation, but here in a useful way: the existence of 
case (over unsaturated constructors) motivates the distinction between II and TL The 
desugaring of case into recursive types built, say, with fix is not nearly as simple as 
the desugaring of let. 

In the end, choices such as these are somewhat arbitrary and come down to taste. 
I believe that the choices I have made here bring us to a useful formalization with 
the right points of complexity. Some of these design decisions are considered in more 
depth after PlCO has been presented; see Section 5.12. 

5.1.3 Other applications of PlCO 

It is my hope that PlCO sees application beyond just in Haskell. In designing it, I have 
tried to permit certain Haskell idioms (call-by-name semantics, the extra capabilities 
of case expressions outlined above) while still retaining a general enough flavor that it 
could be adapted to other settings. I believe that the arguments above about Pico’s 
design mean that it is a suitable starting point for the design of an intermediate 
language for any dependently typed surface language. Other uses might want call-by¬ 
value instead of call-by-name or to remove the somewhat fiddly distinction between 
TI and II. These changes should be rather straightforward to make. 

In certain areas, I have decided not to support certain existing Haskell constructs 
directly in PlCO because doing so would clutter the language, making its applicability 
beyond Haskell harder to envision. Various extensions of PlCO—which would likely 
appear in an implementation of PlCO within GHC—are discussed in Section 5.13. 
These include representation polymorphism and support for the (—>•) type constructor, 
for example. 

5.1.4 No roles in PlCO 

Recent versions of System FC have included roles [11], which distinguish between two 
different notions of type equality: nominal equality is the equality relation embodied 
in Haskell’s (~) operator, whereas representational equality relates types that have 
bit-for-bit identical runtime representations. Tracking these two equality relations is 
important for allowing zero-cost conversions between types known to have the same 
representation, and it is an important feature to boost performance of programs that 
use newtype to enforce abstraction. 

However, roles greatly clutter the language and its proofs. Including them through¬ 
out this dissertation would distract us from the main goal of understanding a de¬ 
pendently typed language with Type : Type and at ease with non-termination. It 
is for this reason that I have chosen to omit roles entirely from this work. (See also 


74 



Section 4.4.3 for a consideration of how roles interacts with the surface language 
proposed here.) I am confident that, in time, roles can be integrated with the language 
presented here, perhaps along the lines I have articulated in a draft paper [27], though 
the treatment there still leaves something to be desired. Regardless of clutter, having 
a solid approach to combining roles with dependent types will be a prerequisite of 
releasing a performant implementation of dependent types in GHC. 

5.2 A formal specification of PlCO 

The full grammar of PlCO appears in Figure 5.1 on the next page and notation 
conventions appear in Figure 5.2 on page 77. We will cover these in detail in the 
following sections. Later sections of this chapter will cover portions of the typing rules, 
but for a full listing of all the typing rules of the language, please see Appendix B. 
Figure 5.3 on page 78 includes the judgment forms and two key lemmas, useful in 
understanding the judgments. All of the metatheory lemmas, theorems, and proofs 
appear in Appendix C. This chapter mentions several key lemmas and theorems, but 
the ordering here is intended for readability and lemma statements may be abbreviated; 
please see the appendix for the correct dependency ordering and full statements. 

You will see that the PlCO language is centered around what I call types, represented 
by metavariables r, a, and k. As PlCO is a full dependently typed language with a 
unified syntax for terms, types, and kinds, this production could be called “expressions” 
and could be assigned the metavariable e. However, I have decided to reserve e (and 
the moniker “expression”) for erased expressions only, after all the types have been 
removed. These expressions are used only in the type erasure theorem (Section 5.11); 
the rest of the metatheory is about types. Nevertheless, a program written in PlCO 
intended to be run will technically be a type, and types in PlCO have an operational 
semantics (Section 5.7). 

As previewed in Section 5.1.1.2, PlCO supports two different forms of n-type: 
the matchable TI and the unmatchable n. It also supports two forms of application: 
Tip is a matchable application and rj/; is an unmatchable one. However, labeling 
all applications would grossly clutter this presentation, and so I just write rip for 
both kinds of applications, where we can discern between them by looking at r’s 
kind. Indeed, the only reason that the grammar has to distinguish between the two 
applications at all is in the consistency proof (Section 5.10), a portion of which works 
in an untyped setting. (See, in particular, the end of Section 5.10.2 for the one place 
where labeling the applications is used.) It is not expected that an implementation of 
PlCO would need to mark the applications, as this mark is redundant with the typing 
information. 

Note also the definition for arguments ip: the application form rip applies a type 
to an argument, which can be a type, an irrelevant type, or a coercion. It would be 
equivalent to have six 46 productions in the definition for types, but having a separate 

46 Product of two application modes (matchable vs. unmatchable) and three relevance modes (type 
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Metavariables: 



T algebraic datatype 

K data constructor 


a, b, x, _ type/term variable 

c coercion variable 


i,j,k,n natural number/index 


n : 

= TI 

matchable dep. quantifier 


1 n 

unmatchable dep. quantifier 

z 

= a\c 

type or coercion variable 

H 

= T\K \ Type 

constant 

P 

= Rel Irrel 

relevance annotation 

8 : 

= a: p K c:(j) 

binder 

(j) : 

=> n K1 ~ K2 t 2 

heterogeneous equality 

,cr,K : 

= a t \t ip\ n<5. r \X8. t 

dependent types 


1 %} 

constant applied to universals 


r > 7 

kind cast 


case K r of alt 

case-splitting 


fixr 

recursion 


absurd 7 r 

absurdity elimination 

iP 

= ^IMIt 

argument 

alt : 

= 7r —y T 

case alternative 

7 r : 

= H\_ 

pattern 

7) V ■ 

— c 

coercion assumption 


| (t') | sym 7 | 7 i 9 72 

equivalence 


1 -^{ 7 } 7^1 n<Up? 7 - 7 lie:( 771 , 772 ) 

. 7 congruence 


case,, 7 of calt fix 7 \\a: p r]. 7 

Ac:(t 7 i, rj 2 ). 7 absurd ( 771 , rj 2 ) 7 


| Ti T 2 

coherence 


argk 7 argk n 7 res n 7 7 @u; 

Il-type decomposition 


| nth n 7 | left,, 7 | right^ 7 

generativity & injectivity 


kind 7 

“John Major” equality 


step t 

/^-equivalence 

calt : 

:= 7T —^ 7 

case alternative in coercion 

u : 

: = 7 |{7> I(7n72) 

coercion argument 

E : 

:= 0 

signature 


| E, T.:(a:K) 

algebraic datatype 


S. :(A: 7’) 

data constructor 

r,A : 

:= 0 |r,<$ 

context / telescope 

9 : 

:= 0 6 >,r/a 0 , 7 /c 

substitution 


Figure 5.1: The grammar of PlCO 
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dom(A) A 
prefix(-) = 

MO = 

H = 

Tip = 

UA.t = 
HA. t = 
AA.r = 
Ti ~ t 2 = 


# = 
L-J = 
y = 

let is 


(an overbar) indicates a list 
a fresh variable whose name is not used 
the list of variables bound in A 
a prefix of a list; length specified elsewhere 
extract all free variables, as a set 
Bq (when appearing in a type) 

Tip or Tjp , depending on r’s kind 
nested ns 

nested ns, where the individual ns used might differ 
nested As 

T\ Kl ~ K2 t 2 (when the kinds are obvious or unimportant) 
an erased coercion 

the sets of free variables of two entities are distinct 
coercion erasure (Section 5.8.3) 
type erasure (Section 5.11) 

used in the metatheory only and should be eagerly inlined 
Figure 5.2: Notation conventions of PlCO 


definition for arguments allows us to easily discuss what I call vectors , 47 which are lists 
of arguments ip. Similarly to the redundancy of application forms, tracking relevant 
types as compared to irrelevant types is also redundant with the kind of the function 
type; an implementation would not need to store this distinction. 

Coercions are the most distinctive and most intricate part of PlCO. Because the 
formation rules for coercions necessarily refer to many other parts of the language, 
a thorough treatment of coercions is delayed until the other constructs are covered. 
However, it may be helpful to readers unfamiliar with System FC to learn a few quick 
facts about coercions: see Figure 5.4 on page 79. 

As you will see in Figure 5.2, my presentation of PlCO uses several abbreviations 
and elisions in its typesetting. In particular, I frequently write types like nA. r to 
represents a nested n-type, binding the variables listed in A (which, as you can see, is 
just a list of binders S). An equality proposition in PlCO lists both the related types 
and their kinds. Often, the kinds are redundant, obvious, or unimportant, and so I 
elide them in those cases. 

All of the metatheory in this dissertation is typeset using ott [82], This tool 
effectively type-checks my work, preventing me from writing, say, the nonsense a:cp, 
which is rightly a ott parsing error. 48 In addition, I have configured my use of ott to 
require me to write the kinds of an equality proposition even when I intend for them 

vs. irrelevant type vs. coercion) 

47 1 have adopted this terminology from Gundry [37]. 

48 Indeed, to include that example in the text, I had to avoid rendering it in ott syntax. 
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E kcH : Ai; A 2 ; tf' 
E; T hfy t : k 
E; T; a ^ w t : k 
E; T 7 : 0 


Constant H has universals A 1; existentials A 2 , and belongs 
to parent type H'. 

Type t has kind k. 

Case alternative n —>• r yields something of kind k when 
used with a scrutinee t 0 of type a. 

Coercion 7 proves proposition 0. 


E; T h^ rop 0 ok 
E; T h^c -0 : A 
E; T 0 : A 

lyig E ok 
E r ok 


Proposition 0 is well formed. 

Vector 0 is classihed by telescope A. 

Vector -0 is classified by telescope A (with induction defined 
from the end). 

Signature E is well formed. 

Context r is well formed. 


E;T kr —» t' 


Type r reduces to type r' in one step. 


Lemma (Kind regularity [Lemma C.43]). //E; T ht y r : k, then E; Rel(r) hty K : Type. 
Lemma (Prop, regularity [Lemma C.44]). // E; T 7 : (j>, then E; Rel(r) ^ rop 0 ok. 


Figure 5.3: Judgments used in the definition of PlCO 


to be elided in the rendered output, as a check to make sure these parameters can 
indeed be written with the information to hand. 

This chapter proceeds by explaining all of the various typing judgments individually. 
Section 5.3 explains contexts T, along with relevance annotations. Section 5.4 explains 
signatures E, which contain specifications for constants H. Having covered the more 
unexpected aspects of the syntax, Section 5.5 then presents examples of PlCO programs. 
Types come next, in Section 5.6, followed by the operational semantics in Section 
5.7. Now having an thorough understanding of the rest of PlCO, we are prepared 
to tackle coercions, the thorniest part, in Section 5.8. Section 5.9 covers one final 
rule from the operational semantics (S_KPush), too challenging to describe before 
coercions are fully explained. Sections 5.10 and 5.11 cover the metatheory. Section 
5.12 describes certain, perhaps unexpected design decisions. The chapter concludes in 
Section 5.13 by considering a variety of extensions to PlCO that are needed for full, 
backward-compatible support for Haskell as embodied in GHC 8 . 


78 





Coercions define the equivalence relation ~ that is used in Pico’s analogue of a 
traditional conversion rule, as presented in Section 5.1. Here is a brief introduction 
to coercions. The full definition of coercion formation rules appears in Appendix B.3. 
The rules are explicated in Section 5.8. 

• Coercions are heterogeneous (Section 5.8.1). If a coercion 7 proves T\ Kl ~ K 2 t 2 , 
then we know that r% is convertible with t 2 and also that reg is convertible 
with K 2 - The form kind 7 extracts the kind equality from the type equality. 
I often elide the kinds when writing propositions, however. 

• Equality may be assumed via a A-abstraction over a coercion variable c, 
proving any arbitrary equality proposition. (Section 5.8.2) 

• Equality is coherent (Section 5.8.3), meaning that a coercion relates any two 
types that are identical except for the coercions and casts within them. The 
coercion form t% ~r, t 2 proves that T\ ~ t 2 and is valid whenever iq and t 2 
are identical, ignoring internal coercions. (The coercion r\ relates the types’ 
kinds.) 

• Equality is an equivalence (Section 5.8.4): (r) is reflexive coercion over r; 
sym 7 represents symmetry; and 71 , 7 2 represents transitivity. 

• Equality is (almost) congruent (Section 5.8.5), meaning that if we have a 
proof of n ~ t 2 , then we can derive a proof relating larger types containing 
Ti and t 2 but are otherwise identical. The “almost” qualifier is due to a 
technical restriction that can be ignored on a first reading. 

• Coercions can be decomposed (Section 5.8.6). For example, if 7 proves 
(Uai.pKi.Ti) ~ (na 2 : p «: 2 . t 2 ), then argk 7 proves «q ~ k 2 - Other coercion 
forms decompose other type forms. 

• The stepr coercion relates r to its small-step reduct. (Section 5.8.7) 


Figure 5.4: A brief introduction to coercions 

5.3 Contexts V and relevance annotations 

One of the distinctive aspects of PlCO is its use of relevance annotations on binders. 
Every variable binding a: p K comes with a relevance annotation p, which can be either 
Rel or Irrel. A typing context T is just a list of such binders (along with, perhaps, 
coercion variable binders) and so retains the relevance annotation. These annotations 
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come into play only in the rule for checking variable occurrences: 


E btx T ok a:Rei« G T 

E; r hfy a : k 


Ty_Var 


Note that this rule requires a: Re \K> e T, with a relevant binder. Thus, only variables 
that are considered relevant—that is, variables that will remain at runtime—can be 
used in an expression. As described briefly above, when we “go up a level”, we reset the 
context, marking all variables relevant. This resetting is done by the Rel(T) operation, 
defined recursively on the structure of T as follows: 


Rel(0) = 0 

Rel(T, a: p n) = Rel(T), a:R e i«: 

Rel(T, c:(f)) = Rel(T), c:cj) 

The Rel(T) operation is used, for example, in the judgment to check contexts for 
validity: 

| E btx T ok | Context formation 


big E ok 
E btx 0 ok 

E; Rel(T) by « : Type a # T 


Ctx_Nil 

E btx T ok 


E btx T, a: p K ok 

E; Rel (T) h prop 0 ok c # £ E btx T ok 


E btx T, c:cj) ok 


Ctx_TyVar 

Ctx_CoVar 


Here, we see that a binding a: p n can be appended onto a context T when the a is 
fresh and the k is well typed at Type in Rel(T). The reason for using Rel(T) instead 
of T here is that the kind k does not exist at runtime, regardless of the relevance 
annotation on a. We are thus free to essentially ignore the relevance annotations 
on T, which is what Rel(T) does. The same logic applies to the use of Rel(T) in the 
Ctx_CoVar rule. Indeed, all premises involving coercions use Rel(T), as all coercions 
are erased and are thus irrelevant. 

In order for premises that use Rel(T) to work in the metatheory, we must frequently 
use the following lemma: 

Lemma (Increasing relevance [Lemma C.6]). Let T and T' be the same except that 
some bindings in T' are labeled Rel where those same bindings in T are labeled Irrel. 
Any judgment about T is also true about IT 
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Regularity Regularity is an important property of PlCO, allowing us to easily 
assume well-formed contexts and signatures: 

Lemma (Context regularity [Lemma C.9]). If 

1. E;T hty t : k, or 

2. E; T bo 7 : or 

3. E; T ^ rop <j> ok, or 

4■ E; T; a 0 b^° t alt : k, or 

5. E; T bee ^ : A, or 

6. E btx T ok, 

then El btx prefix(r) ok and big E ok, where prefix(T) is an arbitrary prefix of T. 
Furthermore, both resulting derivations are no larger than the input derivations. 

5.4 Signatures E and type constants H 

The typing rules in PlCO are all parameterized by both a signature E and a context 
r. Signatures contain bindings for all global constants: type and data constructors. 
In contrast, contexts contain local bindings, for type and coercion variables. Several 
treatments of System FC assume a fixed, global signature, but I find it more precise 
here to make dependency on this signature explicit. 

5.4.1 Signature validity 

The judgment to check the validity of a signature follows: 

I big E ok I Signature formation 


fii g 0 ok 


Sig_Nil 


E ba x a: hre \K ok T#E 
big E, T:(a:K) ok 
T:(a:fi) e E E btx aVei/b A ok 
big E, if:(A; T) ok 


Sig_ADT 


K# E 


SlG 


DataCon 


We see here the two different entities that can belong to a signature, an algebraic 
datatype (ADT) T or a data constructor K. 


81 




An ADT is classified only by its list of universally quantified variables (often 
shortened to universals), as this is the only piece of information that varies between 
ADTs. For example, the Haskell type Int contains no universals, while Either contains 
two (both of kind Type), and Proxy's universals are ( a : Type, b : a). The relevance 
of universals is predetermined (see Section 5.4.2.2) and so no relevance annotations 
appear on ADT specifications. Additionally, coercion variables are not permitted 
here—coercion variables would be very much akin to Haskell’s misfeature of datatype 
contexts 49 and so are excluded. 

A data constructor is classified by a telescope A of existentially bound variables 
(or existentials) and the ADT to which it belongs. The grammar for telescopes is the 
same as that for contexts, but we use the metavariables T and A in distinct ways: F 
is used as the context for typing judgments, whereas A is more often used as some 
component of a type. A telescope is a list of binders—both type variables and coercion 
variables—where later binders may depend on earlier ones. A data constructor’s 
existentials are the data that cannot be determined from an applied data constructor’s 
type. In this formulation, the term existential also includes what would normally be 
considered term-level arguments. 

For example, let’s consider these Haskell definitions: 

data Tuple a where 

MkTuple :: V a. Int —)■ Char —>■ a —>■ Tuple a 
data Ex a where 

MkEx :: V a b. b —>■ a —>■ Ex a 

If I have a value of type Tuple Double, then I know the types of the data stored in a 
MkTuple, but I do not know the Int, the Char, or the Double —these are the existentials. 
Similarly, if I have a value of type Ex Char, then I know the type of one argument to 
MkEx, but I do not know the type of the other; I also know neither value. In this case, 
the second type, b, is existential, as are both values (of types b and a, respectively). 

The use of the term existential to refer to term-level arguments may be non¬ 
standard, but it is quite convenient (while remaining technically accurate) in the 
context of a pure type system with ADTs. 

5.4.2 Looking up type constants 

Information about type constants is retrieved via the E be H : Ai; A 2 ; H' judgment, 
presented in Figure 5.5 on the following page. This judgment retrieves three pieces of 
data about a type constant H: its universals, its existentials, and the head of the result 
type. It is best understood in concert with the typing rule that handles type constants, 
which also uses the typing judgment on vectors—ordered lists of arguments—also 
presented in Figure 5.5 on the next page. Let’s tackle this all in order of complexity. 

49 See discussion of how this is a misfeature at https://prime.haskell.org/wiki/ 
NoDatatypeContexts. 
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E hf c H : A i; A 2 ;H' E ^ tx T ok 

E; Rel(r) h; ec r : Rel(Ai) _ 

E; T ht y H {t} : , n(A 2 [r/dom(A 1 )]). H’r 

————-—-—7771 Type constant kinds, with universals A 1 . 

Zj ht c H \ Za 1: ZX25 -ti . . , • i a i TT/ 

--- 1 existentials ZA 2 , and result H 


E hfc Type : 0; 0; Type 
T:(a:K) e E 

E htc T : 0; a:R e iR; Type 


Tc_Type 

Tc_ADT 


it:(A; T) e S T:(a:K) E E 
E hf c K : a:| rre |7c; A; T 

E; T h^ec ip ’■ A I Type vector formation 


Tc_DataCon 


E hEtx r ok 
E; T hec 0 : 0 


VEC_NlL 


E; T r : /c 
E;Tbec^: A[t/o] 

E; T ly ec r, ip : a: R e |K, A 


Vec_TyRel 


E; Rel(T)Jty r : k 
E; T h^ec V' : A[r/a] 

E; T h7 ec {r}, ip : a:i rre |K, A 


Vec_TyIrrel 


E; Rel(T) 7 : 0 
E; T h^ec 0 • A[y/c] 
E; T h7 ec 7, 0 : c:0, A 


Vec_Co 


Figure 5.5: Type constants H and vectors ip 
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5.4.2.1 The constant Type 


The constant Type has no universals, no existentials, and Type’s type is Type, as 
Tc_Type tells us. Thus, in the use of Ty_Con when H^\ { is just Type^ (normally, 
we omit such empty braces), we see that Ai, A 2 , and r are all empty, meaning that 
we get E; T by Type : Type, as desired. 

5.4.2.2 Algebraic datatypes 

Let’s consider Maybe as an example. We see that the list of universals Ai is empty for 
all ADTs. Thus, the list of universal arguments r must be empty in Ty_Con. The list 
of existentials A 2 is a: Re |Type and the result type root is Type, both by Tc_ADT. 
We thus get E; T by Maybe : TIa:R e |Type. Type, as desired. (Note that a is unused in 
the body of the ’Ll and thus that this type could also be written as Type —y Type.) 

I have argued here how the rules work out this case correctly, but it may surprise 
the reader to see that the argument to Maybe is treated as an existential here—part 
of A 2 —and not a universal. This could best be understood if we consider Type itself 
to be an open ADT (that is, an extensible ADT) with no universal parameters. To 
make this even more concrete, here is how it might look in Haskell: 

data Type where 


Bool 

Type 

Int 

Type 

Maybe 

: Type ->■ Type 

Proxy 

: V (k :: Type), k —* Type 


Thinking of ADTs this way, we can see why the argument to Maybe is existential, 
just like other arguments to constructors (see Section 5.4.1 for an explanation of the 
unusual use of the word existential here). We can also see that the kind parameter k 
to Proxy is also considered an existential in this context. 

The last detail to cover here is the relevance annotation on the a, as assigned 
in Tc_ADT: all the variables are considered relevant. This is a free choice in the 
design of PlCO. Any choice of relevance annotations would work, including allowing 
the user to decide on a case-by-case basis. I have chosen to mark them as relevant, 
however, with the consideration that these ADTs might be present at runtime. There 
is nothing in PlCO that restricts ADTs to be present only at compile time; the user 
might write a runtime computation that returns Bool, for example. 50 (Such a facility 
replaces Haskell’s current TypeRep facility [75].) By marking the ADT parameters as 
relevant, a runtime decision can be made between, say, Maybe Int and Maybe Bool. 
This seems useful, and so I have decided to make these parameters relevant. 

50 This statement does not mean that you can extract the value Maybe Int from Just 3, which 
would require preserving all types for runtime. 






5.4.2.3 Data constructors 


The most involved case is that for data constructors, where both the universals and 
the existentials can be non-empty. We’ll try to understand Ty_Con first by an 
example inspired by the Haskell expression Left True :: Either Bool Char. Let’s recall 
the definition of Either, a basic sum type: 

data Either :: Type — * Type — > Type where 
Left :: a —>• Either a b 
Right :: b —>■ Either a b 

In PlCO this looks like the following: 

E = Either:(a : Type, b : Type), Left:(x: Re \a ; Either), Right:(x: Re \b ; Either ), 
Bool:(0), True:(0 ; Bool), Fa/se:(0; Bool), Char:(0) 

E; 0 by Left {Bool,Char} True : Either Bool Char 

We see how the universal arguments Bool and Char to the constructor Left are specified 
in the subscript; without these arguments, there would be no way to get the type of 
Left True in a syntax-directed way. 

Universal argument saturation The grammar for type constant occurrences in 
types requires them to appear fully saturated with respect to universals but perhaps 
unsaturated with respect to existentials. There are several reasons for this seemingly 
peculiar design: 

• It is helpful to separate universals from existentials in a variety of contexts. For 
example, existentials are brought into scope on a case-match, while universals are 
not. Separating out these arguments is also essential in the step rule S_KPush. 

• If PlCO did not allow matching on unsaturated constants, it might be most 
natural to require saturation with respect to both universals and existentials 
(while still keeping these different arguments separate). This would allow, for 
example, for a simple statement of the canonical forms lemma (Lemma C.75), 
because only a A-expression would have a n-type. 

However, since PlCO does allow matching on unsaturated constants, the grammar 
must permit this form. Because PlCO tracks the difference between matchable 
’n and unmatchable II, we retain the simplicity of the canonical forms lemma, 
as any expression classified by a ’n must be a partially applied constant and any 
expression classified by a II must be a A. 

• All universal arguments are always irrelevant and erased during type erasure 
(Section 5.11). It is thus natural to separate these from existentials in the 
grammar. 
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As with many design decisions, it is possible to redesign PlCO and avoid this 
unusual choice, but in my opinion, this design pays its weight nicely. 

Typing rules for data constructors The Tc_DataCon rule looks up a data 
constructor K in the signature £ to find its telescope of existentials A and parent 
datatype T. The second premise of the rule then looks up T to get the universals. 
The universals are annotated with Irrel, as universals are always irrelevant in data 
constructors—universal arguments are properly part of the type of a data constructor 
and are thus not needed at runtime. The telescope of existentials A and datatype T 
are also returned from hj; c . 

Rule Ty_Con checks the supplied arguments r against the telescope of universals, 
here named Ai. Note that r are checked against Rel(Ai); the braces that appear in 
the production Hpq are part of the concrete syntax and do not represent wrapping 
each individual t e r in braces (cf. Section 5.6.2). Rule Ty_Con then builds the 
result type, a Tl-type binding the existentials and producing H '—that is, the parent 
type T —applied to all of the universals. 

5.5 Examples 

Though these examples may make sense more fully after reading the sections below, it 
may be helpful at this point to see a few short examples of PlCO programs. 

We will work with a definition of length-indexed vectors, a tried-and-true example 
of the design of GADTs. Here is how they are declared in Haskell (further explanation 
is available in Section 3.1.1): 

data Nat = Zero \ Succ Nat 
data Vec :: Type —> Nat —* Type where 
VIMil :: Vec a 0 

VCons :: a —>• Vec a n —>• Vec a ( ’Succ n) 

If PlCO had a concrete syntax, these declarations would be transformed roughly into 
the following: 

Nat :: Type 

Zero :: Nat 

Succ :: Nat —>■ Nat 

Vec :: Type —> Nat —» Type 

VIMil :: V (a :: Type) (n :: Nat), (n ~ Zero ) -4 Vec a n 
VCons :: V (a :: Type) (n :: Nat). 

V (m :: Nat). (n ~ Succ m) —>• a Vec a m —>• Vec a n 

The change seen here is just the transformation between specifying a GADT equality 
constraint via a return type in a declaration to using an explicit existential variable 
with an explicit equality constraint. 





In the abstract syntax of PlCO, these declarations are represented by this signature 

S 0 : 

E 0 = Nat:(0), 

Zero:(0 ; Nat), 

Succ:(_: Re \Nat ; Nat), 

Vec: (a : Type, n : Nat), 

VNil:(c:n ~ 0; Vec), 

VCons:(m:\ ne \Nat, c:n ~ Succ m, _: Re i a, _:r 6 i Vec a m; Vec) 

Let’s walk through these declarations. Our binding for Nat includes an empty list of 
universally quantified type variables. This binding is followed by specifications for 
Zero, which lists no existential variables and is a constructor of the datatype Nat, and 
Succ, which has one (anonymous) existential variable and also belongs to Nat. The 
bindings for Vec and its constructors are similar, but with more parameters. Note the 
coercion bindings in the telescopes associated with VNil and VCons, as well as the 
irrelevant binding for the existential m of VCons. The design we see here, echoing the 
Haskell, does not permit runtime extraction of the length of a vector. If we changed 
the m to be relevant, then runtime length extraction would be trivial. 

We will now look at a few simple operations on vectors, first in Haskell and then 
in Pico. 51 


5.5.1 isEmpty 

First, a very simple test for emptiness, in order to familiarize ourselves with pattern- 
match syntax in PlCO: 

isEmpty :: Vec a n —>• Bool 
isEmpty VNil = True 

isEmpty (VCons { }) = False 

Translated to PlCO, we get the following: 

isEmpty : n(a:| rre |Type), (n:| rre | Nat), (v: Re | Vec a n). Bool 
isEmpty = A(a:i rre |Type), ( n: Wrei Nat ), (v: Re i Vec an). 
cas e Bo oi v of 

VNil X(c:n ~ 0), (c 0 :v ~ VNil{ a , n } c). True 

VCons ->• \(m: ine \Nat), ( c:n ~ Succ m), (x: Re |a), (xs: Re i Vec a m), 

( c 0 :v ~ VConsm cxxs). 

False 

The most striking feature about this PlCO code is the form of the case expression. 
Unlike the concrete syntax of Haskell, patterns in PlCO do not directly bind any 

51 In these examples, I assume the use of numerals to specify elements of type Nat, and I also 
assume the existence of, e.g., Bool. 
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arguments. Note that there are no variable bindings to the left of the arrows in the 
case-branches. Instead, I have chosen to have As to the right of the arrow. This design 
choice greatly simplifies the typing and scoping rules for pattern matches, because it 
removes a binding site in the grammar (leaving us with two: n and A). Because of the 
typing rule for case expressions (Section 5.6.5), we still must bind all of the existentials 
of a data constructor when matching against it—even when these existentials are 
ignored, as we see here. 

The matches also bind a variable not mentioned in the data constructors’ exis¬ 
tentials: the coercion variable c 0 . This coercion witnesses the equality between the 
scrutinee (v, in this case) and the applied data constructor that introduces the case 
branch. This coercion variable is bound in all matches, meaning that all pattern 
matching in PlCO is dependent pattern matching. 52 

The behavior of case can also be viewed through its operational semantics, as 
captured in the following rule, excerpted from Section 5.7.2: 


alti = H —>• r 0 

S; T b case K H^y ip of alt —> r 0 ip (i/pq fp) 


S_Match 


Note that the body of the match, r 0 , is applied to the existential arguments to 
and a coercion witnessing the equality between the scrutinee and the pattern. In the 
case of a successful match, this coercion is reflexive, as denoted by the angle brackets 
<%}# 


5 . 5.2 replicate 

Let’s now look at replicate , one of the simplest functions that requires a proper II-type. 
First, in Haskell: 

replicate ::U n a Vec a n 

replicate Zero = VNil 

replicate (Succ m) x = VCons x (replicate m x) 


52 Contrast to Gundry [37], who use two separate constructs, case and dcase, only the latter 
of which does dependent matching. This separation is necessary in his language because not all 
expressions can be used in types and thus in dependent pattern matching. In particular, Gundry 
prevents A-expressions in types, a limitation I have avoided by maintaining the distinction between 
matchable and unmatchable II-types. 




Now, in PlCO: 

replicate : n(a:i rre |Type), (n: Re] Nat), (x: Re ia). Vec a n 
replicate = Aa:i rre |Type. 

fixA(r: Re in(n: Re |/Vat), (x: Re ia). Vec an), 

( n: Re \Nat ), (x: Re ia). 
case Vec an n of 

Zero —> Ac 0 :(n ~ Zero). VNil^y c 0 

Succ —> Am: Re |A/at, c 0 :(n ~ Succ m). VCons{ ajn y {m} c 0 x (r mx) 

This example shows the (standard) use of fix as well as some of the more exotic 
features of PlCO. In the case branches, we see how we pass universal arguments to 
the data constructors VNil and VCons. We also see how we have to wrap irrelevant 
arguments (the {m} in the last line) in braces. This example also shows where the 
coercion variable c 0 comes into play: it’s needed to provide the coercion to the VNil 
and VCons constructors to prove that the universal argument n is indeed of the shape 
required for these constructors. Without the ability to do a dependent pattern match, 
this example would be impossible to write, unless you fake dependent types using 
singletons or some other technique. 

5 . 5.3 append 

We’ll now examine how to append two vectors. This operation will also require the 
use of an addition operation, defined using prefix notation so as not to pose a parsing 
challenge: 

plus :: Nat —»■ Nat —>• Nat 

plus Zero n = n 

plus (Succ m) n = Succ (plus m n) 

append :: Vec a m —^ Vec a n —>• Vec a (’p/ns m n) 

append VNil ys = ys 

append (VCons x xs) ys = VCons x (append xs ys) 
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And in PlCO (where I elide the uninteresting plus for brevity): 

append : IJ(a:| rre |Type), ( m: lrrei Nat ), (n: Wrei Nat), (xs: Re \Vec a m), (ys: Rel Vec a n). 

Vec a (plus m n) 
append = A(a:i rre |Type). 

fix X(app: Re \U(m: hre \Nat), (. n: irrei Nat ), (xs: Re i Vec a m), (ys: Re \Vec a n). 

Vec a (plus m n)), 

{.m: hrei Nat), ( n: Wrei Nat ), (xs: Rel Vecam), (ys: Re |Vec a n). 

case Vec a (plus m n) *S of 

VIMil —> X(c:m ~ Zero), (co'.xs ~ VNih [3m j c). 
let ci := (p/us) c (n) in 
let c 2 := step- 7 (plus Zero n ) in 

ys > sym (Vec (a) (ci ° 9 c 2 )) 

VCons—> A(m': hrel Nat), (c:m ~ Succ m'), (x: Rei a), (xs': Re \Vec a m') 

( co'.xs ~ \/Cons{ a)m } {m'} cxxs'). 
let ci := {plus) c (n) in 
let c 2 := step fc (p/us (Succ m ') n) in 
VCons{ a ^ p i usmn j {plus m’ n}(ci° 9 c 2 )x (app {m '} {n} xs' ys) 

This is the first example where we are required to write non-trivial coercions. 
Let’s start by considering the right-hand side of the VNil case. As we see in the 
Haskell version, we wish to return ys. However, ys has type Vec a n, and we need 
to return something of type Vec a (plus m n). We must, accordingly, cast ys to have 
type Vec a (plus m n). This is what the coercion sym (Vec (a) (ci, c 2 )) is doing; it 
proves that Vec an is in fact equal to Vec a (plus m n). Both the starting type 
Vec a n and the ending type Vec a (plus m n) have the same prefix of Vec a. We 
use a congruence coercion (Section 5.8.5) Vec (a) 7 to simplify our problem. Now, we 
need only a coercion 7 that proves plus m n equals n. (The use of sym helpfully has 
reversed our proof obligation.) This 7 is built in two steps, tied together by using our 
transitivity operator Ci, which uses our reflexivity operator (•), proves that plus m n 
equals plus 0 n by using c, the GADT equality constraint from the VNil constructor; 
and c 2 proves that plus 0 n equals n. 53 For this last coercion, we use the step coercion 
that reduces a type by one step. It is fiddly (and unenlightening) to calculate the 
precise number of steps necessary to get from plus 0 n to n, so I have just written that 
this takes j steps. It is straightforward to calculate j in practice. 

The coercion manipulations in the VCons case are similar. 

Also of note in this example is the interplay between relevant variables and irrelevant 
ones. We see that the lengths m and n are irrelevant throughout this function. Indeed, 
we do not need lengths at runtime to append two vectors. Accordingly, we can see that 
all uses of m and n (or m’) occur in irrelevant contexts, such as coercions or irrelevant 
arguments to functions. 

53 Recall (Figure 5.2 on page 77) that let is defined by simple expansion. It is not properly a 
language construct but instead is just a convenient abbreviation in this writeup. 




5 . 5.4 safeHead 


With length-indexed vectors, we can write a safe head operation, allowed only when 
we know that the vector has a non-zero length: 

safeHead :: Vec a ('Succ n) —> a 
safeHead (VCons x _) = x 

Note that safeHead contains a total pattern match; the VNU alternative is impossible 
given the type signature of the function. This function translates to PlCO thusly: 

safeHead : n(a:| rre |Type), (n: Wre \Nat), (v: Rei Vec a (Succ n)). a 
safeHead = A(a:i rre |Type), (n: Wrei Nat), (v: Re i Vec a (Succ n )). 
case 3 v of 

VNU —>• A (c:Succ n ~ Zero), (c 0 : v ~ VNil{ a! s U ccn} c). absurd c a 
VCons —>• A(m:| rre |A/at), (c:Succ n ~ Succ m), (x: Re ia), (xs: Re | Vec a m), 
(c 0 :v ~ l/Cons {a)SuC c n } {m} cxxs). 
x 

The new feature demonstrated in this example is the absurd operator, which 
appears in the body of the VNU case. In order to be sure that case expressions do 
not get stuck, the typing rules require that all matches are exhaustive. However, in 
general, in can be undecidable to determine whether the type of a scrutinee indicates 
that a certain constructor can be excluded. In order to step around this potential 
trap, PlCO supports absurdity elimination through absurd. The coercion passed into 
absurd (c, above) must prove that one constant equals another. This is, of course, 
impossible, and so we allow absurd 7 r to have any type r. 


5.6 Types r 

Having gone through several examples explaining the flavor of PlCO code, let’s now 
walk through the remaining typing rules of the system. Recall that we have already 
seen the typing rules for variables, Ty_Var in Section 5.3, and constants, Ty_Con 
in Section 5.4.2. 




5.6.1 Abstractions 


The definition for types r includes the usual productions for a pure type system, 
including both a fl-form and a A-form: 


E ; r,Rel(5) k : Type 
E; T hty 115. k : Type 


E; T, 5 ht y t : n 
E; T by A 8. t: U8. k 


Ty_Lam 


The only novel component of these rules is the use of Rel(5) in the premise to Ty_Pi. 
This is done to allow the bound variable to appear in k, regardless of whether it is 
relevant or not. As an example, the use of Rel(5) here is necessary to allow the type of 
Haskell’s T: IIa:| rre |Type. a. 


5.6.2 Applications 

Terms with a n-type (either type constants or A-terms) can be applied to arguments, 
via these rules: 


E; T hty Ti : na: Re |Ki. k 2 E; T hf y r 2 : 
E; T hfy T\ t 2 : k 2 [t 2 /a] 


Ty_AppRel 


E; T hfy Ti : na:| rre |/ci. k 2 E; Rel(T) h^ r 2 : K\ 
E;T h^ Ti{t 2 } : k 2 [t 2 /o\ 


Ty_AppIrrel 


E; r by T : ILc:<f>. k E; Rel(T) bo 7 : </> 

E;T by Ty : /cfy/c] 


Ty_CApp 


We see in these rules that the argument form for an abstraction over an irrelevant 
binder requires braces. (See the conclusion of Ty_AppIrrel.) The system would 
remain syntax-directed without marking off irrelevant arguments, but type erasure 
(Section 5.11) would then need to be type-directed. It seems easier just to separate 
relevant arguments from irrelevant arguments syntactically. 

Note also the use of Rel(T) in Ty_AppIrrel and Ty_CApp; resetting the 
context here happens because irrelevant arguments and coercions are erased in the 
running program. 


92 



5.6.3 Kind casts 

We can always use an equality to change the kind of a type: 

E; Rel(r) bo 7 : «i ~ k 2 

T hfy t : E; Rel(r) hty k 2 : Type 

- -——--- Ty_Cast 

E; I by t > 7 : k 2 

In this rule, a type of kind K\ is cast by 7 to have a type k 2 - As always, the coercion 
is checked in a reset context Rel(r). The final premise, E; Rel(T) by k 2 : Type is 
implied by the first premise (which is actually E; Rel(T) bo 7 ; /Ci Type ~ Ty P e k 2 ) via 
proposition regularity, but we must include it in order to prove kind regularity 54 before 
we prove coercion regularity. 

5.6.4 fix 

PlCO supports fixpoints via the following rule: 


E; T ht v t : IIa:Rei/Y k 

- y ———- Ty Fix 

E; T by fixr : k 

The rule requires type r to have an unmatchable II so that we can be sure that r’s 
canonical form is indeed a A (as opposed to an unsaturated constant); otherwise the 
progress theorem (Section 5.7) would not hold. 

5.6.5 case 

Unsurprisingly, the typing rules to support pattern matching are the most involved 
and are presented in Figure 5.6 on the following page with the rules to type-check 
case branches. 

Most of the premises of Ty_Case are easy enough to explain: 

• The result kind of a case, k is given right in the syntax; the first premise 
E; Rel(T) by « : Type ensures that it is a valid result kind. 

• We also must check the kind of the scrutinee, t. This kind must have the 
form TIA. H a (note the matchable ’II), where the a cannot mention any of the 
variables bound in A. (The E; Rel(r) by Ha: Type premise checks this scoping 
condition.) Note that the scrutinee’s type may be a Tl-type in order to support 
matching against partially applied type and data constructors. 

• The alternatives must be exhaustive and distinct. Exhaustivity is needed to 
prove that a well-typed case cannot get stuck, and distinctness is necessary to 
prove that the reduction relation is deterministic. 


54 Both regularity lemmas are stated in Figure 5.3 on page 78. 



Ty_Case 


E; Rel(r) k : Type E; T hf y r : a 
a = 'll A. II a E; Rel(T) Ha: Type 
Vi, E; F; cr ff )t alti : k 

alt are exhaustive and distinct for if, (w.r.t. E) 
E; T ht y case K r of alt : k 
S;r;ahl, t alt : k | Case alternatives 


E hf c H : A i; A 2 ; H' A 3 , A 4 = A^/don^AO 
dom(A 4 ) = dom(A / ) 

match{ dom (A 3 )} (types( A 4 ); types( A')) = Just# 

E; T ht y r : HA 3 , c:r 0 ~ H { ^ dom(A 3 ). k 


E^TIA'.tf'crh® H - 
E; T hfy t : k 
_->r: 


Alt_ Match 


Alt Default 


types(A) = r | Extract the types from a telescope 


types(0) — 0 

types(A, a: p n) = types(A), k 
types(A, c:t% K1 ~ K2 t 2 ) = types(A), ki, k 2 ,%r 2 


Figure 5.6: Rule and auxiliary definitions for case expressions 


We are left to consider type-checking the alternatives. This is done via the judgment 
with schema E; T; a alt : k. When E; T; a alt : k holds, we know that the 
expression in the case alternative alt produces a type of kind k when considered with 
signature E and typing context T and when matched against a scrutinee r of type a. 
The premises of Ty_Case indeed check that all alternatives satisfy this judgment. 

5.6.5.1 Checking case alternatives 

The rule Alt_Match is intricate. It assumes a scrutinee To of type TIA'. H'a, and 
we are checking a case alternative H —>• r. 

First, we must verify that the constant H is classified by H 1 —that is, either H is 
a data constructor of the datatype H' or if is a datatype and H' is Type. We say 
that H' is the parent of H. This check is done by the E hf c H : A 4 ; A 2 ; H' premise, 
which also extracts the universals A 4 and existentials A 2 . 

The next premise (reading to the right) uses A 2 [a/dom(Ai)] to instantiate the 
existentials with the known choices for the universals. These known choices a are 
obtained from determining the type of the scrutinee; see the appearance of a in the 
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type appearing before the hii t in the conclusion of the rule. The second premise also 
splits the instantiated existentials into two telescopes, A3 and A4. 

Note that A' is an input to this rule; it is extracted from the type of the scrutinee. 
Accordingly, the third premise dom(A4) = dom(A') serves two roles: it fixes the length 
of A 4 (and, hence, A 3 ) and it also forces any renaming of bound variables necessary 
to line up the telescopes A' and A 4 . Keeping the names of the bound variables 
consistent between these telescopes simplifies this rule. We see that in the event that 
the scrutinee is a fully saturated datatype or data constructor, A 4 = A' = 0 and 
A 3 = A 2 [(t/dom(A 1 )]; in this common case, then, unification is unnecessary. 

The next premise uses a one-way unification algorithm to make sure that the 
bound telescope in the scrutinee’s type, A', matches the expected shape A 4 . (The 
types operation appears in Figure 5.6 on the previous page.) We will return to this in 
Section 5. 6 .5.2, below. In the common case of A' = 0 (that is, full saturation of the 
scrutinee), this premise is trivially satisfied. Also note that we do not use the output 
of this premise, 6 , anywhere in the rule, so skipping it on a first reading is appropriate. 

Lastly, we must check that the body of the alternative, r, has the right type. This 
type must bind (by any combination of matchable ’ll and unmatchable II—recall 
that this is the meaning of H from Figure 5.2 on page 77) all of the existentials in 
A 3 , as well as the coercion variable witnessing the equality between r 0 (the scrutinee) 
and the applied H. In this rule the use of dom(A 3 ) as a list of arguments to H^} is 
a small pun; we must imagine braces surrounding any variable in dom(A3) that is 
irrelevantly bound. The return type of the abstraction in r must be k, the result kind 
of the overall match. 

For examples of this in action—at least in the fully saturated case—see the worked 
out examples above (Section 5.5). 

5.6.5.2 Unification in Alt_Match 

Let’s examine the use of unification in Alt_Match more carefully. We will proceed 
by examining two examples, a simple one where unification is unnecessary and a more 
involved one showing why we sometimes need it. 

Our first example was given above, when first describing unsaturated matching 
(Section 5.1.1.2): 

type family IsLeft x where 
IsLeft ’Left = ’True 
IsLeft ’Right = ’False 

The translation of Either into PlCO appears in Section 5.4.2.3. This type family 
translated to the following PlCO function (rewritten to be lowercase according to 
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Haskell naming requirements): 


isLeft : n(a:, rre |Type), (x: Re |TI(y: Re |a). Either a a). Bool 
isLeft = A(a:i rre |Type), (x: Re |’n(y: Re ia). Either a a), 
case Booi x of 

Left —>• Ac 0 :(x ~ Left{ a , a })- True 
Rights Ac 0 :(x ~ Right ^ aa ^). False 

Comparing the first alternative against Alt_Match, we see the following concrete 
instantiations of metavariables: 


H= Left 

Ai = s:, rre |Type, t:, rre |Type 

A 2 = y:Re|S 

H'= Either 

T 0 = X 

A'= y: Re ,a 


cr = a, a 
A 3 = 0 
A 4 = y: Re ia 
9 = 0 

t— A(c 0 :x ~ Left { a , a >). True 
K— Bool 


In this example, the constructor is not applied to any existential variables, and so 
A 3 , the telescope of binders that are to be bound by the match, is empty. The only 
variable bound in the match body is Co, the dependent-match coercion variable. Also 
note that A 4 , the instantiated suffix of the telescope of existential arguments to Left, 
and A', the telescope of binders in the type of the scrutinee, coincide. Accordingly, 
the match operation succeeds with an empty substitution 9 = 0. 

In contrast, the following example shows why we need unification in Alt_Match: 

data X where 

MkX : : a —> a —> X 

— NB: a is existential; no universals here 

type family UnX (x :: Bool > X) :: Bool where 
UnX (’MkX y) = y 

Note that we’re extracting the first (visible) argument from an unsaturated use of 
MkX. This Haskell code translates to the following PlCO: 

E=X:(0), 

MkX:(a: , rre |Type, y: Re |3, z: Re |3; X) 


unX : n(x: Re |’n(z: Re |Boo/). X). Bool 
unX = A(x: Re |’n(z: Re |Boo/). X). 
case Boo /*of 

MkX -4 A(a:i rre |Type), (y: Re ia), (c 0 :x n^Booiyx^n^yx M /cXay). 
y > sym (argk (kind c 0 )) 

Before we get into the minutiae of Alt_Match, let’s dwell a moment on the cast 



necessary in the last line. According to both the type of unX and the return type 
provided in the case, the match must return something of type Bool. Yet the body of 
a match must bind precisely the existential variables of a data constructor; according 
to the definition of MkX, the variable y has type a, not Bool. We thus must cast y 
from a to Bool. We do this by extracting out the right coercion from Co. This c 0 is 
heterogeneous; I have typeset the code above with the kinds explicit to show this. 
The left-hand kind is the declared type of x, binding z of type Bool. The right-hand 
kind is the kind of MkX a y, which binds z of type a. By using kind (which extracts 
a kind equality from a heterogeneous coercion; see Section 5.8.1), followed by argk 
(which extracts a coercion between the kinds of the arguments of Il-types; see Section 
5.8.6.1), and then sym (which reverses the orientation of a coercion), we get the 
coercion needed, of type a ~ Bool. 

Now, we’ll try to understand the matching in Alt_Match. Let’s once again 
examine the concrete instantiations of the metavariables in the rule: 

H= MkX o= 0 

Ai= 0 A 3 = a:i rre |Type,y: Re ia 

A 2 = a:i rre |Type,y:Reia,z: Re ia A 4 = z: Re ,a 

H'= X 9 = Bool/a 

r 0 = x t = (as above) 

A'= z: Re \Bool K— Bool 

Recall that A 3 and A 4 are the prefix and suffix, respectively, of the telescope of 
existentials A 2 , after this telescope has been instantiated with the known arguments 
for the universals. However, with MkX, there are no universals at all (the datatype 
X takes no arguments), and so this instantiation is a no-op. (The lack of universals 
shows up in the equations above via an empty A 4 and an empty a.) We thus have 
A 3 , A 4 = A 2 , where the length of A 4 must match the length of A', the telescope 
of variables bound in the type of the scrutinee. We see that the scrutinee x has 
type Tl(z: Re \Bool). X and so A' = z: Re \Bool. Thus A 3 —the existentials bound by the 
pattern match—has two elements (a and y) and A 4 has one (z). 

We now must make sure that the shape of the types in A' match the template 
given by the types in A 4 . That is, A' must be some instance of A 4 , as determined 
by a unification algorithm (discussed in more depth in Section 7.3). In this case, the 
unification succeeds, assigning the type variable a to be Bool, as shown in the choice 
for 9, above. Accordingly, the match is well typed. 

Requiring this unification simply reduces the set of well typed programs. It is thus 
important to understand why the restriction is necessary. What goes wrong if we omit 
it? The problem comes up in the proof for progress, in the case where the scrutinee 
has a top-level cast. We will use step rule S_KPush (see Section 5.9); that rule has 
several typing premises 55 which can be satisfied only when this match succeeds. The 
restriction is quite technical in nature, but any alternative not ruled out by the type 

55 These unexpected typing premises to a small-step reduction rule are addressed in Section 5.7.4. 
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of the scrutinee should be acceptable. See the proof of progress in Appendix C.ll for 
the precise details. 

5.6.5.3 Default alternatives 

PlCO supports default alternatives through the form _ —| r. This is a catch-all 
case, to be used only when no other case matches. In a language with a simpler 
treatment for case statements, a default would be unnecessary; every case could 
simply enumerate all possible constructors. However, PlCO has two features that 
makes defaults indispensable: 

• When matching on a scrutinee of kind Type (or, say, a function returning a 
Type), it would be impossible to enumerate all possibilities of this open type. 
Such matches must have a default alternative. 

• If a scrutinee is partially applied, the typing rules dictate a delicate unification 
process to make sure alternatives are well typed. (See Section 5. 6 .5. 2 .) Given 
the design of Alt_Match, it is possible some of the constructors of a datatype 
would be ill typed as patterns in an unsaturated match. It might therefore be 
challenging to detect whether an unsaturated match is exhaustive. To avoid 
this problem, unsaturated matches may use a default alternative in order to be 
unimpeachably exhaustive. 

Happily, the typing rule Alt_Default for default alternatives could hardly be 
simpler. 


5.6.5.4 Absurdity 

We saw in the safeHead example (Section 5.5.4) the need for absurdity elimination 
via the absurd operator. Here is the typing rule: 


E;Rel(T) 

E; Rel(T) by r : Type 

E; T by absurd 7 t : t 


H, ^ H 2 

- Ty_Absurd 


This rule requires that the coercion argument to absurd, 7 , relate two unequal type 
constants H\ and H 2 . The type absurd 7 r can have any well formed kind, as chosen 
by r. Because r is needed only to choose the overall kind of the type, it is checked a 
context reset by Rel. 

As explained with the example, absurdity elimination is sometimes needed in 
the body of case alternatives that can never be reached. In a language that admits 
undefined , the absurd construct is not strictly necessary. Yet by including it, we can 
definitively mark those alternatives that are unreachable. Simply returning undefined 
would not be as informative. 



5.7 Operational semantics 

Now that we have seen the static semantics of types, we are well placed to explore 
their dynamic semantics—how the types can reduce to values. The dynamic semantics 
of types is expressed in PlCO via a small-step operational semantics, captured in the 
judgment E; T 1^ r —> t' . Rules in this judgment are prefixed by “S_”. It must be 
parameterized over a typing environment because of the push rules, as explained in 
Section 5.7.4. 

The operational semantics obeys preservation and progress theorems. 

Theorem (Preservation [Theorem C.46]). If T,;T t : k and E; T 1^ r —> t' , then 
E; T hfy t' : k. 

Theorem (Progress [Theorem C.78]). Assume T has only irrelevant variable bindings. 
If^TkyT-.K, then either t is a value v, r is a coerced value v > 7 , or there exists r' 
such that E; T 1^ t — > r'. 

The progress theorem is non-standard in two different ways: 

• As discussed shortly (Section 5.7.1), reduction can take place in a context with 
irrelevant variable bindings. 

• The progress theorem guarantees that a stuck type is either a value v or a 
coerced value v > 7 . This statement of the theorem follows previous work (such 
as Weirich et al. [105]) and is applicable in the right spot in the proof of type 
erasure (Section 5.11). 

The operational semantics are also deterministic. 

Lemma (Determinacy [Lemma C.20]). //E; T hi r —> a\ and E; T r —> then 

<Ji = cr 2 . 

5.7.1 Values 

A subset of the types t are considered values, written with the metavariable v: 

Definition (Values). Let values v be defined by the following sub-grammar ofr: 

v ::= | ID. r | Xa: Re \n. r | Aa:| rre |K. v \ Xc-.fi. t 

As we can see, values include applied constants, Il-types, and some A-types. 
However, note a subtle but important part of this definition: the production for 
irrelevant abstractions is recursive. An irrelevant abstraction Aa:i rre |K. r is a value if 
and only if r, the body, is also a value. This choice is important in order to prove type 
erasure. 

Our definition of values also gives us this convenient property: 
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Lemma (Value types [Lemma C.76]). //E;T by v : k, then k is a value. 

During compilation, we erase irrelevant components of an expression completely. 
This includes irrelevant abstractions. Thus, the erasure operation, written [[•]] and 
further explored in Section 5.11, includes this equation, 

[[Aa:| rr e|K.TjJ = |f_[J, 

erasing the abstraction entirely. Yet we must make sure to maintain the following 
lemma, referring to the definition of values on erased expressions: 

Lemma (Expression redexes [Lemma C.84]). If [[tJJ is not a value, then r is not a 
value. 

If we have the equation above erasing irrelevant abstractions to the erasure of their 
bodies but call all irrelevant abstractions values (that is, make Aa:i rre i«;. r a value for all 
t), then this lemma becomes false. To wit, suppose r is not a value. Then |J_Aa:i rre | /v. tJJ 
would not be a value, but Xa:\ rre \K. r would be. Thus, in order to maintain this lemma, 
we have a recursive definition of values for irrelevant abstractions and, accordingly, 
evaluate under irrelevant abstractions as well. See rule S_IrrelAbs_Cong in Section 
5.7.3. 


5.7.2 Reduction 

Several of the small-step rules perform actual reduction in a type: 

S_BetaRel 


E;T b (\a: Re \K. offjJi —> CTi^/a] 

E; T (Aa:| rre |AC- Vi)Jya 2 } —¥ Vi[a 2 /a] 

E; T hg (A c:(j). a)si —► (j[ 7 /c] 
alti = H —y To 

E; T lg case K H^y tjj of alt —> t 0 V' ( H{t} V’) 
alf — —¥ a no alternative in alt matches H 


S BetaIrrel 


E; T b case K Hy T y of alt —> a 
alf = _ —^► cr no alternative in alt matches H 

E; T lg case K Hy^y 4 * > 7 °f alt — > cr 
r = Aa: Re |«;. a 


S_CBeta 

S_ Match 

S_ Default 


S DefaultCo 


E;T ii fixr —» cr[fixr/a] 


S_ Unroll 


too 



Note that S_BetaIrrel requires a value v\ in the body of the abstraction in order 
to keep the rules deterministic. The only other surprising feature in these rules is the 
way that S_Match works by applying the body of the alternative To to the actual 
existential arguments to H{t} and a reflexive coercion. This follows directly from my 
design of having case alternatives avoid a special binding form and use the existing 
forms in the language. 

The Beta rules above make explicit that the application is an unmatchable 
application tj/j. This is actually redundant, as all A-abstractions are unmatchable. I 
have included the notation here to make it clearer how these rules line up with the 
rules in the parallel rewrite relation used to prove consistency (Section 5.10.2). 


5.7.3 Congruence forms 

PlCO has several uninteresting congruence forms, 


SjTfiff- 


> cr '-0 


E; r hi a > 7 — 
E; T h; cr — 
E; T b case T a of alt — 
E; T hi t - 


> a' > 7 


S_App_Cong 


S Cast Cong 


> case T o' of alt 


S Case Cong 


E; T hi fixr - 

and one more unusual one: 


S Fix Cong 


> fixr' 


E; T, a:| rre |R hi a —>■ cr' 

E; T hi Aa:| rre i«;. cr —> \a\\ rre .\K. cr' 


S_IrrelAbs_Cong 


This last rule allows for evaluation under irrelevant abstractions, as described in 
Section 5.7.1. It must add the new irrelevant variable to the context, but is otherwise 
unexceptional. 


5.7.4 Push rules 

A system with explicit coercions like PlCO must deal with the possibility that coercions 
get in the way of reduction. For example, what happens when we try to reduce 

((A x: Re | Bool, x) > (Bool)) True ? 

Casting by a reflexive coercion should hardly matter, and yet no rule yet described 
applies here. In particular, S_BetaRel does not. 
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E;T fi (v > 71) > 72 


v > (719 72) 


S_ Trans 


E; Rel(r) l^ 0 70 : Ua:R e \K. a ~ IIa:Rei/V. o' 

71 = sym(argk7o) 72 = 7 0 @(t > 71 ^ sym71 t) 

E; T hi (d > 70) t — >• v (t > 71) > 72 


S_PushRel 


E; Rel(r) 7 0 : IIa:| rre | 7 c. a ~ na:| rre |/V. cr' 

71 = sym(argk7o) 72 = 7 0 @(t > 71 ft* sym7l 

E; T (u > 70) {t} —> v {r > 71} > 72 


t) 


S_PushIrrel 


E; Rel(r) h^o 70 : Uc:(f>. a ~ II c:(j)' . a' 

71 = argk, 70 72 = argk 2 7 0 

rf = 7 i 9 V 9 sym 72 73 = 7 o@(*/, v) 

E; T fi (7; > 70) 77 —> ?; 77' > 73 


S_CPush 


7l = na:| rre |(/{). 7 72 = Ti ~(Type) T 2 

Ti = IJaVeiK. (/«i[a > sym (k)/ a]) r 2 = Ua: inei K. ^ 

E; T k Aa:i rre |N. (u > 7) —» (Aa:i rre |N. v) > (71 § 72) 


S_APush 


71 = 7 o@(a ~ 7 2 a > 72) 9 sym72 

_ 72 - argk 70 _ 

E; T fi fix ((Aa:Rei/c. a) > 70) —» (fix (Aa: Re |N. (cr > 71))) > 72 


S_FPush 


E ht c 1/ : a:i rre |K; A; H' A = Ai,A 2 n = |A 2 | 
re = ’IIa:| rre |N, A. H' a 
a = , n(A 2 [T/a]['0/dom(Ai)]). H't 
a' = , U(A 2 [t'/ a]^'/dom(Ai)]). H't' 

E; Rel(r) 77 : a - a' 

E; Rel(r) h^ ec r' : a:R e |ft 

Vi, 7 i = build_kpush_co((N)@(nths (res n 77)); 

Vi, — cast_kpush_arg('0j; 7,) 

H —> tc / E alt 

E; T ^ case K0 (R{r} 4>) > 77 of a ^ —>• case K0 #{t'} V’ °f a ^ 


S_KPush 


Figure 5.7: Push rules 


102 




To deal with this and similar scenarios, PlCO follows the System FC tradition and 
contains so-called push rules, as shown in Figure 5.7 on the previous page. These rules 
are fiddly but—ignoring S_KPush for a moment—straightforward. They simply serve 
to rephrase a type with a coercion in the “wrong” place to an equivalent type with the 
coercion moved out of the way. The rules can be derived simply by following the typing 
rules and a desire to push the coercion aside. Compared to previous work, the novelty 
here is in rules S_APush (which handles reduction under irrelevant abstractions and 
must take into account the awkward substitution in Co_PiTy; see Section 5. 8 .5.1) 
and S_FPush (which handles fix, never before seen in System FC), but these rules 
again pose no design challenge other than the need for attention to detail. 

Many of the push rules share an odd feature: they have typing judgment premises. 
These premises are the reason that the stepping judgment is parameterized on a typing 
context. In order to prove the progress theorem, it is necessary to prove consistency 
(Section 5.10), which basically says that no coercion (made without assumptions) can 
prove, say, Int ~ Bool. Still ignoring S_KPush, the consistency lemma is enough 
to admit the typing premises to the push rules. However, using consistency here 
would mean that the preservation theorem depends on the consistency lemma, while 
consistency is normally used only to prove progress. In seems to lead to cleaner proofs 
to avoid the dependency of preservation on consistency, and so these typing premises 
are necessary. 

The S_KPush rule is very intricate and makes use of a variety of coercions. 
Explicating this rule in its entirety is best saved until after we have covered coercions 
in more depth. See Section 5.9. 


5.8 Coercions 7 

PlCO comes with a very rich theory of equality, embodied in the large number of 
coercion forms. We will examine these forms in terms of the properties they imbue 
on the equality relation. Note that the coercion language is far from orthogonal; it is 
often possible to prove one thing in multiple ways. Indeed, GHC comes with a coercion 
optimizer [96] that transforms a coercion proving a certain proposition into another, 
simpler one proving the same proposition. Enhancing this optimizer is beyond the 
scope of this dissertation, however. It is needed only as an optimization in the speed 
of compilation and is not central to the theory or metatheory of the language. 

All coercions are erased before runtime (Section 5.11). Accordingly, we check for 
well typed coercions (via the judgment E; T 1^ 0 7 : (j>) only in contexts reset by the 
Rel(-) operator. 

5.8.1 Equality is heterogeneous 

The equality relation in PlCO is heterogeneous, allowing ~ to relate two types of 
different kinds. This is most clearly demonstrated in the rule for the well-formedness 
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of propositions: 56 


| r fj^rop (f> ok Proposition formation 


E; r ht y Ti : /ti 
E; r ht y t 2 : k 2 
S; r fprop n Kl ~* 2 r 2 ok 


Prop _ Equality 


Note that the kinds K\ and k 2 are allowed to differ. 

The particular flavor of heterogeneous equality in PlCO is so-called “John Major” 
equality [58], where an equality between two types implies the equality between the 
kinds: 


E; T bo 7 : Ti Kl ~* 2 t 2 
E; r bo kind 7 \ ^ k 2 


Co_Kind 


As we can see, the kind coercion form extracts a kind coercion from a type coercion. 

Though I have described my equality relation following McBride [58], he uses 
identity proofs in quite a different way than I do here. His language confirms that an 
identity proof is reflexive and then brings definitional equalities of the types and kinds 
into scope. The surface Haskell version of heterogeneous equality works quite like 
McBride’s. My invocation of “John Major” here is to recall that an equality between 
types implies the same relationship among the kinds. 

It’s worth pausing here for a moment to consider two other possible meanings, 
among others, of heterogeneous equality: 


Trellys equality The equality relation studied in the Trellys project [13] a hetero¬ 
geneous equality with no equivalent of the kind coercion. That is, if we have a proof of 
Ti Kl ~ K2 r 2 , then there is no way to prove ~ k 2 (absent other information). Indeed, 
Trellys equality (that is, omitting the Co_KlND rule) would work in PlCO; that 
coercion form is never needed in the metatheory. Omitting it would weaken Pico’s 
equational theory, however, and so I have decided to include it. 


Flexible homogeneous equality Another potential meaning of heterogeneous 
equality is that and n 2 might not be identical—as they would be in a traditional 
homogeneous equality relation—but they are propositionally equal. 57 Such an equality 

56 This rule is the entire judgment—there is no other form of proposition supported in PlCO. 

57 I am distinguishing here between definitional equality and propositional equality. The former, in 
Pico, refers to a-equivalence. Definitional equality is the equality used implicitly in typing rules when 
we use the same metavariable twice. If written explicitly, it is sometimes written =. Propositional 
equality, on the other hand, means an equality that must be accompanied by a proof; in PlCO, ~ is 
the propositional equality relation. Languages with a Conv rule (Section 5.1) import propositional 
equality into their definitional equality. PlCO does not do this, requiring a cast to use a propositional 
equality. 
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would use this rule (not part of Pico): 


E; T hfy Ti : Ki E; T hfy r 2 : k 2 
E; T bo 7 : «q ~ n 2 

-——- — --- Prop_Homogeneous 

El; r fprop Ti K1 ~ 7 2 t 2 ok 

Note how ~ is indexed by 7 , the proof that the kinds are equal. I call this equality 
homogeneous, because even to form the equality T\ ~ t 2 , we must know that the kinds 
are equal. Contrast to Prop_Equality, where the proposition itself is well formed 
even when the kinds and/or types are not provably equal. 


5.8.2 Equality is hypothetical 

A key property of equality in PlCO is that programs can assume an equality proof. 
This is how GADTs are implemented, by packing an equality proof into a nugget of 
data and then extracting it again on pattern match. In the body of the pattern match, 
we can assume the packed equality. Here is the typing rule: 


e b* r ok c-4 e r 
E; T bo c : </ 


Co_Var 


Coercion variables are brought into scope by n and A over coercion binders. 


5.8.3 Equality is coherent 

Pico’s equality relation is coherent , in that the precise locations and structure of 
coercions within types is immaterial. This is a critical property because it is intended 
for a compiler to create and place these coercions. The type system must be agnostic 
to where, precisely, they are placed. Coherence is obtained through this coercion form: 


e ; r bo v ■ «u ~ « 2 Lnj = LtjJ 

E; r by Ti : K\ E; r by t 2 ■ ^2 

E; T bo Tl r 2 : Ti ~ t 2 


Co_ Coherence 


This coercion form requires two well kinded types r x and t 2 as well as a coercion 77 
that relates their kinds. It also requires the critical premise that [dJ = \r 2 \, where 
L-J is a coercion erasure operation. This operation is separate from (though similar 
to) the type erasure operation spelled [[•]] and discussed several times thus far. The 
full definition of this operation is given in Definition C.47. Briefly, coercion erasure 
is defined recursively on types, binders, case alternatives, and propositions by the 
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following equations, treating other forms homomorphically: 

L r i\ m 1'J • L t >tJ = L r J 

[absurdqrj = absurd# |_tJ L( c: ^)J = ( #: L^J) 

As we can see coercion erasure simply removes the coercions from a type. We use 
• to stand in for an erased coercion application. I sometimes use the metavariable 
e to stand for a type that has its coercions erased, but r and a may also refer to a 
coercion-erased type, if that is clear from the context. 

By using coercion erasure in its premise, the coherence coercion can relate any two 
types that are the same, ignoring the coercions. This is precisely what we mean by 
coherence. 

The coherence rule implies that any two proofs of equality are considered inter¬ 
changeable. In other words, PlCO assumes the uniqueness of identity proofs (UIP) [44], 
This choice makes PlCO “anti-HoTT”, that is, incompatible with homotopy type 
theory [91], which takes as a key premise that there may be more than one way to 
prove the identity between two types. While baking UIP into the language may limit 
its applicability, Pico’s intended role as an intermediate language, where the coercions 
are inferred by the compiler, makes this choice necessary. We would not want the 
static semantics of our programs to depend on the vagaries of how the compiler placed 
its equality proofs. 

Note that the coherence form in PlCO is rather more general than the coherence 
form used in my prior work [105]. The way I have phrased coherence is critical for my 
consistency proof. See Section 5.10.5 for more discussion. 


5.8.4 Equality is an equivalence 

The equality relation ~ is explicitly an equivalence relation, via these rules: 
E; T hh, t : k 


E; r (r) : r - 
E;Tbo7:Ti - 


Co Refl 


E; T h^o symq : t 2 ~ t i 
E; T hEo 7i : n ~ t 2 E; T 1^, 72 : t 2 ~ t 3 


E; T bo 7i 9 72 : n ~ t 3 
Note the use of (r) to denote a reflexive coercion over the type r. 


Co _ Trans 


5.8.5 Equality is (almost) congruent 

Given coercions between the component parts of two types, we often want to build a 
coercion relating the types themselves. For example, if we know that E; r bo 7i : Ei ~ a \ 
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and E; T bo 72 : t 2 ~ cr 2 , then we can build E; T bo 7172 : Ti t 2 ~ (7\ a 2 . The form 
71 72 is typed by a congruence rule; each form of type has an associated congruence 
rule. The rules that do not bind variables appear in Figure 5.8 on the following page; 
I’ll call these the simple congruence rules. Rules that do bind variables are subtler; 
they appear in Figure 5.9 on page 109. 

The simple congruence rules simply build up larger coercions from smaller ones. 
With the exception of Co_ Absurd, they assert that the types related by the coercion 
are well formed; it is easier simply to check the types than to repeat all the conditions 
in the relevant typing rules. The typing premises for absurd are simple enough on 
their own, however. 

The notation I use for congruence rules deliberately mimics that of types. However, 
do not be fooled: the coercion 71 72 does not apply a “coercion function” 71 to some 
argument. The coercion 7172 never /^-reduces to become some 7 [ 72 /c]. Similarly, the 
A-coercion (one of the binding congruence forms) does not define a A-abstraction over 
coercions; it witnesses the equality between two A-abstraction types. 

Two of the congruence rules— Co_CApp and Co_Absurd —relate types that 
mention coercions. In these congruence rules, the coercion 7 must explicitly mention 
the two coercions that appear in the respective locations in the related types, as we 
do not have a coercion form that relates coercions. For example, examine Co_CApp, 
declaring that 70 (71,72) relates Ti 71 and t 2 72, given that 70 relates T| and t 2 . Instead 
of (71,72) appearing in the coercion, we might naively expect some 77 that relates 71 
and 72 ; since such an 77 does not exist in the grammar, we just list the two coercions 
71 and 72. The syntax for Co_ Absurd is similar. 

5. 8 .5.1 Binding congruence forms 

The binding coercions forms (Figure 5.9 on page 109) all have a particular challenge 
to meet. Suppose we know that E; T bo V '■ K i ~ K 2 and we wish to prove equality 
between Iia: p K\. T\ and Ua: p n 2 . t 2 . We surely must have a coercion 7 relating 77 to t 2 . 
But in what context should we check 7 ? We cannot assign a both «q and k 2 . 

In PlCO, I have chosen to favor the left-hand kind in the context and do a 
substitution in the result. Let’s examine Co_PiTy closely. The coercion 77 indeed 
relates /q and k 2 . The coercion 7 is checked in the context T, a: Re | 7 q—note the use 
of K\ there. Regardless of the relevance annotation p on the coercion, the context 
is extended with a binding marked Rel, echoing the use of Rel(5) in the premise to 
Ty_Pi (Section 5 . 6 . 1 ). The types related by 7 (cq and a 2 ) might mention a, assumed 
to be of type /q. For <q, that assumption is correct; the left-hand type in the result is 
Yia: p K\. <q . However, for cr 2 , this assumption is wrong: we wish a to have kind k 2 in the 
right-hand result type. In order to fix up the mess, the conclusion of Co_PiTy does 
an unusual substitution, mentioning the type a 2 [a > sym 77 /a]. This takes cr 2 —well 
typed in a context where a has kind /q—and changes it to expect a to have kind k 2 . 
It does this by casting a by sy 11177 , a coercion from k 2 to /q. We can thus use the 
(standard) substitution lemma (Lemma C. 35 ) to show that this result type is itself 
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Co_Con 


Vi, E; T 7* : cr, ~ o' i 
E; T hf y : «i E; T ht y //{^j : k 2 
E;T bo 


E; r hEo 71 : n ~ t 2 
E; r 72 : (Ti ~ cr 2 

E; T hty Ti cri : Ki E; T by t 2 cr 2 : k 2 
E; T h^o 7i 72 : n o’i ~ t 2 <t 2 


Co_AppRel 


E; T 7i : ri ~ r 2 
E; T h^ 0 72 : cti ~ a 2 

E;T hfy Ti {(Ti} : Ki E; T by t 2 {a 2 } : k 2 
E; T hEo 7i {72} : Tl {ai} ~ t 2 {(t 2 } 


Co_AppIrrel 


E; T 70 : Ti ~ t 2 

E; T hty Ti 71 : Ki E; T by r 2 72 : ^2 
E; T bo 70 ( 71 , 72 ) : Ti 71 ~ t 2 72 


Co_CApp 


E; T bo 77 : Ri ~ E; T bo 70 : Ti ~ t 2 

Vi, E; T hEo 7i : CTj ~ 

alt 1 — alt 2 = 7Tj —>• cr' 

E; r hfy case Kl Ti of alti : K\ E; T by case K2 t 2 of alt 2 : k 2 
E; T hEo case,, 70 of 7r* —p# : case Kl Ti of a/ti ~ case K2 t 2 of alt 2 


Co_Case 


E; T hEo 7 : Ti ~ t 2 

E; T hfy fix Ti : Ki E; T by fix t 2 : k 2 

E; T hEo fix 7 : fix Ti ~ fix t 2 


Co_FlX 


E; r Vo 7i : ^{r l} Vh ~ ^ {r ' l} fi 7^ 

E; r hEo 72 : #2{r 2 } i>2 ~ ^2{r^} V 4 #2 7^ H 2 
E; T hEo ~ 

E; r hEo absurd (71,72) rj : absurd 71 /ci ~ absurd 72 r 2 


Co_Absurd 


Figure 5.8: Congruence rules that do not bind variables 
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Co_PiTy 


E; T rj : k x T yp e ~ T yp e K2 

_ S;r,a: Rel ^ 7 ; ^ Type^Type a2 _ 

E; T bo II a: p rj. 7 : (Ua: p Ki. ay) ~ (Ua: p K 2 . ( a 2 [a > sym 77/a])) 

E; r 771 : Ti ~ r 2 E; T bo 772 : 04 ~ cr 2 

E; r, C-.Tx ~ CTi b 0 7 : Kj Type^Type ^ C ^ 7 

m = Vi 9 c 9 sym 772 

E; T bo He:(771, 772). 7 : (IIc:Ti ~ 04. *4) ~ (II c:t 2 ~ <t 2 . (/c 2 [W c ])) 


E; T bo 77 : K\ ~ tc 2 
E; T, a\ p K\ bo 7 : T i ~ t 2 

E, r, d.pK\ by *7”1 - C7" 1 E ? r,(7.p/v^ by 7”2 . (7 2 

E;T (-jo Aa: p 77-7 : Aa: p 7Ci.Ti ~ \a: p K 2 . (r 2 [a > sym 77/a]) 


Co_Lam 


E; T bo 771 : T\ ~ t 2 E; T bo 772 : 04 ~ a 2 

E; T, c:ti ~ 04 b 0 7 : K4 ~ tc 2 c # 7 

_ 773 = Vi 9 c ; sym 772 _ 

E; T bo Ac:(77i, 772). 7 : (Ac:ti ~ 04. t%) ~ (Ac:t 2 ~ <r 2 - (k 2 [W c D) 


Co_CLam 


Figure 5.9: Congruence rules that bind variables 


well typed, as needed to prove regularity (Lemma C.44). The other binding congruence 
forms use similar substitutions in their conclusions, for similar reasons. 

This extra substitution in the conclusion is indeed asymmetric and a bit unwieldy , 58 
but this treatment is, on balance, better than the only known alternative. Other 
type systems similar to PlCO [37, 92, 105] use an entirely different way of handling 
congruence coercions with binders: instead of trying to treat a as a variable with two 
different kinds, they invent fresh variables. What I write as Ila:^. 7 , they would write 
as n,,(ai, a 2 , c). 7 , binding ai : K\ and a 2 : k 2 , as well as a coercion c : ai ~ a 2 . You can 
see either of those works for the details, but I have found this construction worse than 
the asymmetrical version. Other than the bookkeeping overhead of extra variables, 
the three-variable version also requires us to introduce a coercion variable even when 
making a congruence coercion over a II-type over a type variable. Coercion variables 
in the context cause trouble (as discussed in Section 5.10.3), and my one-variable 
version helps to contain the trouble. See Section 5.10.5.3 for more discussion. 

As a further support to my choice of a one-variable binding form with an asym¬ 
metrical rule, I have implemented both versions in GHC. Initially, I implemented the 
three-variable form from Weirich et al. [105]. This worked, but it was often hard to 
construct the coercions, and it was sometimes a struggle to find names guaranteed to 

58 See the statement of the push rule S_APush (Section 5 . 7 . 4 ) for an example of how its unwieldiness 
can bite. 
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be fresh. When I refactored the code to use the one-variable version formalized here, 
the code became simpler. 

5.8.5.2 Congruence over coercion binders 

The congruence forms over types that bind coercion variables (rules Co_PlCo and 
Co_CLam) have two more wrinkles. The first is that there is no equivalent of 
Co _ PiTy’s t) coercion that relates two propositions; we must settle for the pair of 
coercions (771,772) that appear in Co_PlCo and Co_CLam. These coercions relate 
corresponding parts of the propositions. The second wrinkle is in the c # 7 premise of 
both of these rules. 

Definition (“Almost devoid”). Define c # 7 (pronounced “7 is almost devoid of c”) 
to mean that the coercion variable c appears nowhere in 7 except, perhaps, in one of 
the types related by a T\ t 2 coercion. 

The almost-devoid condition on Co_PlCo and Co_CLam restricts where the 
bound variable c can appear in the coercion body. This technical restriction, based 
on the original idea by Weirich et al. [105], is necessary for my proof of consistency 
(Section 5.10) to go through. The motivation for the restriction is discussed in depth 
in Section 5.10.3. 

The key example that this restriction forbids looks like this: 

£;T & Hc:((lnt), (Bool)), c : (.Ylc.lnt ~ Bool. Int ) ~ ( Hc:lnt ~ Bool. Bool) 

It would seem that this coercion would not cause harm, yet I know of no way to prove 
consistency while allowing it. See Section 5.10.5 for a discussion of other approaches. 

Happily, this restriction is not likely to bite when translating Dependent Haskell 
programs to PlCO, as we can write functions witnessing the isomorphism between the 
two types related above: 

to : n(x: Re |(nc:/nt ~ Bool. Int)). (n c:lnt ~ Bool. Bool) 
to = X(x: Re \(Ilc:lnt ~ Bool. Int)), ( c:lnt ~ Bool), (x c) > c 
from : n(x: Re |(nc:/nt ~ Bool. Bool)), (n c:lnt ~ Bool. Int) 
from = A(x: Re |(nc: Int ~ Bool. Bool)), ( c:lnt ~ Bool), (x c) > sym c 

A compiler of Dependent Haskell creates functions such as these as it is compiling 
a subsumption relationship <, as discussed further in Section 6.4.2. In other words, 
while we don’t have (nc:/nt ~ Bool. Int) ~ (nc:/nt ~ Bool. Bool), these two types 
are related by <, in both directions. This mean that a Dependent Haskell program 
that expects one of these types in a certain context, but gets the other type, is still 
well typed. 

When can the lack of the equality proof bite? Only when that proof is needed as a 
coercion argument to some function or GADT constructor. As we’ve just seen, using 
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it to cast is unnecessary, as we can just use one component of the isomorphism. The 
forbidden equalities all relate fl-types over coercions. Yet, in Dependent Haskell, an 
abstraction over an equality constraint is considered a polytype. Passing a polytype 
as an argument is considered a use of impredicativity, which is not supported. (See 
Section 4.4.4.) In particular, the equality constraint (( Int ~ Bool ) =k Int ) ~ ((Int ~ 
Bool ) =>- Bool ) is malformed in Dependent Haskell, because it passes polytypes as 
arguments to ~. I thus conjecture that no Dependent Haskell program is ruled out 
because of the coercion variable restriction. Proving such a claim seems challenging, 
however, and remains as an exercise for the reader. 

5.8.5.3 (Almost) Congruence 

The coercion variable restriction means that equality is not quite congruent, according 
to the following definition: 

Definition (Congruence). Equality is congruent if, whenever E; r bo 7 : cr 2 and 

B;T, a\ p K by r : kq, there exists rj such that E; T bo rj : t[u\/ a\ ««[o-i/°]^«o[<r 2 /«] -7-[cr 2 /a] ■ 

If we were to try to prove that equality is congruent, it seems natural to proceed 
by induction on the typing derivation for r. However, in the proof, we are stuck when 
r = A c:cj). t 0 . The congruence form for A-types over coercions is no help because of the 
coercion variable restriction . 59 If we strengthen the induction hypothesis to provide 
what we need in this case, then other cases fail, unable to obey the restriction. 

As a concrete example, consider this: Let T = y: Re \lnt, c: 3 ~ y and r = X(c':lnt ~ 
Bool). x> c'. We know E; T bo c : 3 ~ y and E; T, x: Re \lnt by r : n(c':/nt ~ Bool). Bool. 
Yet there seems to be no way to construct a proof of t[3/x] ~ r\y/x]. m 

Instead of proving congruence, I am left proving almost-congruence, as follows: 

Definition (Unrestricted coercion variables [Definition C.87]). Define a new judgment 
fj : 0 to be identical to bo? except with the c # 7 premises removed from rules Co_PlCo 
and Co_CLam and all recursive uses of bo replaced with b D - 

Now, the proof for the following theorem is straightforward: 

Theorem ((Almost) Congruence [Theorem C.90]). Equality is congruent with the 
judgment lj: 0 . 

59 Contrast to the proof of the lifting lemma in my prior work [106]; that proof relies on a critical 
auxiliary lemma (their Lemma C.7) which requires a different coercion variable restriction than what 
I am using here. Furthermore, I show in Section 5.10.5.2 that their restriction is too weak. 

60 It is tempting to try to prove this by using the Co_CLam form and then coherence forms 
stitched together with transitivity; after all, the c # 7 restriction in Co_CLam does not affect the 
types in a coherence coercion. However, the g coercion in the coherence coercion (77 relates the kinds 
of the types mentioned in the coherence coercion) must still be devoid of c, and that is where this 
plan falls apart. 
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What this means, in practice, is that we can often think of equality as congruent, 
and intuition about the equality relation stemming from congruence is often accurate. 
In particular, if the type r in the statement of congruence has no coercion abstractions 
or 11 -types, then congruence with respect to bo holds . 61 

5.8.5.4 Consequences of congruence 

Congruence is not, thankfully, a necessary property of PlCO. Nowhere in the metatheory 
do we rely on this result (or lack thereof). 

In the implementation, however, congruence 62 is used to perform some coercion 
optimizations [96]. After desugaring Haskell into its Core language (currently based 
on the version of System FC as described in my prior work [105]), GHC optionally 
performs coercion optimization, in the hope of converting large coercions into smaller 
ones that prove the same propositions. This speeds up compilation and reduces the 
size of the interface files that GHC writes to disk to store information about compiled 
modules; the optimization has no effect at runtime, however, because coercions are 
fully erased before execution. 

Congruence comes into play when optimizing a coercion such as (n a\ p r\. 71)@72, 
where 71 @72 is a decomposition form that instantiates a n-type (Section 5. 8 . 6 .2). 
Without going into further detail, in order to perform the instantiation requested, we 
must find exactly the coercion suggested in the definition of congruence above. Since 
PlCO lacks congruence, the updated coercion optimizer sometimes fails to optimize 
these coercions. The troublesome case—when we would run afoul of the c # 7 
restrictions in Co_PlCo and Co_CLam —is easy to detect, and the optimization is 
simply skipped when this were to happen. The lack of congruence does not otherwise 
bite. 

5.8.6 Equality can be decomposed 

PlCO comes equipped with a large variety of ways of decomposing an equality to get 
out a smaller one—in some sense, these are the inverses of the congruence forms. We 
will approach these in batches. 

5.8.6.1 The argk forms 

The coercion form argk extracts a coercion between the kinds of the bound variables 
in a coercion relating abstractions. The rules appear in Figure 5.10 on the next page. 
The rules are actually straightforward; look at Co_ArgK for a typical example. This 
form extracts the equality between «q and K 2 from the type of 7 . The other forms work 

61 This intuition is hard to state precisely, because of the possibility that the contexts have abstrac¬ 
tions over coercions. We would somehow need a premise that states that no coercion abstractions are 
“reachable” from r, but defining such a property and then proving this claim seems not to pay its way. 
62 What I call congruence here has been called the lifting lemma in the literature. 
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Co_ArgK 


S; r h^o 7 : (Ua: p Ki. <Ti) ~ (Ua: p K 2 . <J 2 ) 

E; r bo argk 7 : K\ ~ k 2 

E;T bo 7 : (IIc:(ti ~ ~ (n c:(t 2 ~ t' 2 ).(J 2 ) 

E; T bo argk x 7 : 77 ~ t 2 

E; T 7 : (nc:(Ti ~ r{).o-i) ~ (IIc:(t 2 ~ t^).<t 2 ) 
E; T bo argk 2 7 : t( ~ t 2 
E; T bo 7 : (Xa-.pKi. a t ) ~ (Xa: p K 2 . cr 2 ) 

E; T bo argk 7 : K\ ~ r 2 

E; T bo 7 : (Ac:(ti ~ rfi.ai) ~ (Ac:(t 2 ~ t' 2 ).o 2 ) 


Co CArgKI 


Co CArgK2 


Co ArgKLam 


E; T bo argk : 7 : n ~ t 2 
E; T 7 : (Ac:(ti ~ t().< 7 i) ~ (Ac:(t 2 ~ 7 ^).<t 2 ) 
E; T bo argk 2 7 : r[ ~ t 2 


Co_CArgKLam1 


Co_CArgKLam2 


Figure 5.10: The argk rules of coercion formation 


analogously. The forms with argk, are necessary because PlCO has no built-in notion 
of an equality between equalities: If we tried to extract a relation between propositions 
like we do in Co_ArgK, we would need something that looks like 4> 1 ~ 4>2, which 
does not exist in PlCO. So, we have to extract either the left side of the propositions 
or the right side. 

Note that these rules are syntax-directed even though their conclusions overlap: 
we can always find the proposition a coercion proves and then decide which argk rule 
to use. 

5. 8 . 6 .2 The instantiation forms 

Given a coercion between abstractions, we can instantiate the bound variable and 
get a coercion between the instantiated bodies. The rules for these coercions are in 
Figure 5.11 on the following page. 

These rules are essentially concrete instances of two rule schemas, one for instanti¬ 
ation coercions built with @, and the other for “result” coercions built with res. The 
instantiation coercions can work with one of three argument types (relevant type, 
irrelevant type, and coercion) and one of two forms (II and A), leading to six very 
similar rules. Along the same lines, res coercions work with both II and A, though 
this form is agnostic to the argument flavor, so we get only two rules. 

The instantiation coercions are essential in writing the push rules (Section 5.7.4) 
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Co_InstRel 


E; T h^ 0 7 

: Ila: 

Rel^l- <Ti ~ 

na: Re iR 2 .<T 2 

E; T h^o 77 

: Ti K 

r 2 


E; T h^ 0 

7@77 

: <Ji [t\/ a] 

~ <?2 [t 2 / a] 

E; T h^o 7 : 

na:, ri 

elR 1 • 0-1 ~ 

IIa:|rre|R2- 02 

E; T h^o 77 : 

n^r 

- K2 t 2 


E; T h^ 0 7 @{t7} 

: ai[Ti/a] 

~ <%bs/a] 

E; T h^ c 

. VI : ] 

[lc: 0 i. cti ~ flc: 0 2 . cr 2 

E; T h^ c 

> 71 : ' 

0 i E 

; r 72: 02 


E;T 77 i@( 7 i, 7 2 ) : cr x [71/c] ~ a 2 [l2/c\ 


Co_InstIrrel 


CO_ClNST 


E; r 7 : Aa: Re i/ci. t% ~ Aa: Re iR2- t 2 
E; T 77 : <7i K1 ~ K2 cr 2 
E;T 7@?7 : Ti[cri/a] ~ r 2 [cr 2 /a] 


Co_InstLamRel 


E; T h^o 7 : AaiirreiKi. n ~ Aa:i rre iR 2 . t 2 
E; T h^o 77 : <Ji 2 cr 2 


E; T 7@{t 7> : Ti[(Ji/a] - T 2 [<r 2 /a] 


Co_InstLamIrrel 


E; T 7 : Ac: 0 i. <Ti ~ Ac: 0 2 . cr 2 

E; r 771 : E; r 772 : 02 

E; T h^ 0 7 @(t7i, 77 2 ) : ^[771/c] ~ cr 2 [772/c] 


Co_CInstLam 


E; T h ^ 0 7 : HAi. ti ~ HA 2 . t 2 |Ai| = |A 2 | = 71 

E; T ht y n : Type E; T ^ t 2 : Type _ 

E; T h ^ 0 res n 7 : 77 ~ t 2 


Co _ Res 


E; T h^o 7 : AAi. ti ~ AA 2 . t 2 |Ai| = |A 2 | = ti 
E; T hty Ti : Ri E; T hfy t 2 : r 2 

E; T h^ 0 res n 7 : 77 ~ t 2 


Co_ResLam 


Figure 5.11: Instantiation rules of coercion formation 
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of the operational semantics . 63 

The res coercions are a form of degenerate instantiation, usable when the body 
of an abstraction (either II or A) does not mention the bound variable(s). Note that 
both res rules require that the body types (iq and t 2 ) are well typed without any 
of the bound variables in Ai or A 2 . These coercions also allow for the possibility of 
looking through multiple binders. This ability cannot be emulated by repeated use of 
res because of the possibility of an intermediate dependency. For example, consider 
the reflexive coercion 7 = (II(a:| rre |Type), ( 6 : Re ia). Type). We can see that res 2 7 is 
well typed, even though res 1 7 is not (because of the appearance of a in the type of b). 

We must use res instead of instantiation when we don’t have a coercion to use 
for the instantiation. This situation happens in the S_KPush rule, where we need 
a coercion relating the bodies of two propositionally equal II-types, but we have no 
coercions to hand to use in instantiation. See Section 5.9 for more details. 


5.8.6.3 Type constants are injective 

In PlCO, all type constants are considered injective, as witnessed by the nth coercions, 
which extract an equality between arguments of a type constant: 


E; T bo 7 : #{*} ip ~ H {li > } $ 
ipi — t ip} = a 

E; T t : Ki E; V by cr : k 2 
E; T bo nthj 7 : t ~ cr 

E; T bo 7 : #{«} ^ ~ #{«'} $ 

A = M i>'i - M 

E; Rel(r) by t : E; Rel(r) by cr : k , 2 

E; T bo nth* 7 : t ~ cr 


NthRel 


Co_NthIrrel 


Both forms above require that we extract a coercion between type arguments, never 
coercion arguments. As discussed in Section 5.8.3, we never need an explicit proof 
of equality between coercions. The last line of premises in the rules are simply to 
produce the kinds to put in the result proposition, where the kinds are elided in the 
typesetting. 

Injectivity of type constants is sometimes controversial [104] and is known to be 
anti-classical [47]. However, in a type system with Type : Type, being able to prove 
absurdity by combining type constant injectivity with, say, the Law of the Excluded 
Middle, does not weaken any property of the language. Injectivity is vital in the 
S_KPush rule and is thus a part of the language. 

63 It is necessary for the system to allow instantiation on II-types; A-types, on the other hand, are 
not strictly necessary to instantiate in order to prove type safety. However, doing so is easy, and so I 
took the opportunity to make the equality relation stronger. 
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Co_Left 


E; T 7 : Tij 0 i ~ t 2 j 0 2 
E; T hfy Ti : TI< 5 i. Ki E; F hf y t 2 : TI( 5 2 . k 2 
E; T 77 : TI^.K! ~ TL$ 2 .k 2 

E; T left,, 7 : Ti ~ r 2 

E; T h^o 7 : T\_(T 1 ~ r 2 _cr 2 
E; T hfy cti : E; T cr 2 : k 2 E; T 77 : ~ r 2 

E; T h^o right,, 7 : 07 ~ cr 2 


Co_RightRel 


E; T h^o 7 : Ti_{(Ti} ~ t 2 _{ct 2 } 

E; T hfy 07 : «i E; T hf y cr 2 : k 2 E; T 77 : K\ ~ tc 2 
E; T hEo right,, 7 : <Ji - a 2 


Co_RightIrrel 


Figure 5.12: Function application decomposition coercions 

5 .8.6 .4 Matchable types are generative and injective 

In Section 4.2.4,1 define matchable as the conjunction of generative and injective. PlCO 
includes two coercion forms that witness the generativity (left) and injectivity (right) 
of matchable function types, as shown in Figure 5.12. Note that the applications in the 
proposition proved by 7 are matchable applications rjp , distinct from unmatchable 
applications rji>. 

Interestingly, these coercions require an extra coercion 77 that proves that the kinds 
of the output types are equal. This kind coercion is necessary to prove the consistency 
of the kind coercion (Section 5.8.1). It is curiously absent from my prior work on kind 
equalities [105], but I now believe that this coercion is necessary—though I have yet to 
find a counterexample to consistency by omitting it, I am unable to prove consistency 
without it. 

Does adding this extra argument to left and right now weaken Pico’s expressive¬ 
ness, compared to its predecessors? Yes and no: 

Yes, fewer coercions are available, when comparing against the system in my 
prior work [105]. However, I argue in Section 5.10.5.2 that the proof in that prior 
work is broken, precisely around its kind coercion. If PlCO reduces expressiveness 
compared to an unsound system, this may be an improvement. 

No fewer coercions are available, when comparing against the System FC before 
kind equalities (that is, the System FC in GHC 7). Prior to GHC 8 , the left 
and right coercions required the kinds of the output types to be identical. In 
those cases, the 77 coercion in Pico’s left and right would just be reflexive. 
Though this restriction on the kinds was overlooked in the original publication 
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on System FC [87], it appears in later treatments [11, 32], 64 


I thus conclude that adding these extra kind coercions is appropriate, considering that 
their omission in GHC 8.0 may be unsafe and that including them is conservative 
with respect to GHC 7. 


5.8.7 Equality includes /3-reduction 

The last rule to consider in the bo judgment is the one that witnesses /3-reduction: 


r by r '■ K E; r by t ; : « 

E; r b T — ► t ' 

E; T bo stepr : r ~ r' 


Co_Step 


This rule is in place of having /3-equivalence be part of definitional equality, as 
is done in some other dependently typed languages, such as Coq. Instead, in order 
to get a type to reduce, a PlCO program must invoke the step coercion explicitly. 
Generating these coercions is quite painful to do by hand (as seen in the example in 
Section 5.5.3), but straightforward for a compiler. 65 

You will see that the rule requires both the redex and the reduct to be well kinded 
at kind k. The requirement on the reduct is implied by the preservation theorem 
(Theorem C.46), but omitting it from the rule means that the proofs of proposition 
regularity (Lemma C.44) and preservation would have to be mutually inductive. It 
seems simpler just to add this extra, redundant premise. 


5.8.8 Discussion 

The coercion language in PlCO is quite extensive, boasting (or suffering from, depending 
on your viewpoint) 37 separate typing rules. I consider here, briefly, why this is so. 

There are several coercion forms (to wit, 10) that are absolutely essential for PlCO 
to be proven type-safe and yet remain meaningful. These include the equivalence and 
coherence rules, assumptions, the n-congruence form over type variables, 66 argk over 
n, instantiation over n, injectivity, and /3-reduction. With the exception of assumptions 
(Co_Var) and /3-reduction (Co_Step), these forms are all needed somewhere in the 
push rules (Section 5.7.4). 67 Assumptions and /3-reduction, however, make PlCO what 

64 The left and right coercions were omitted entirely from Yorgey et al. [107]. Correspondingly, 
they were dropped from the implementation in GHC 7.4. However, users found that this omission 
prevented some programs from being accepted. See GHC ticket #7205. 

65 If a type must reduce many times, it would be more efficient to support a step” coercion form 
that performs n steps at once. Indeed, this is what I plan to implement. It is easier, however, to 
prove properties about single-step reduction. 

66 This form is needed only to support reduction under irrelevant As. 

67 I am considering here a version of Pico without unsaturated matches. If we wish to include 
unsaturated matches, we would also need res over n. 
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it is; the language would be near useless as a candidate for an internal dependently 
typed language without these. 

The rest of the forms merely enrich the equality relation, while remaining inessential. 
I have decided to include them to make the equality relation relate more types. Doing 
so makes PlCO—and, in turn, Dependent Haskell—more expressive. When adding 
rules, we must be careful that the new forms do not violate consistency (or other 
proved properties), so they are not entirely free. Perhaps there are more useful, safe 
rules one could add later, simply by updating the relevant proofs. Because PlCO 
never inspects the structure of a coercion, adding new rules introduces only a minimal 
burden on any implementation—essentially just for bookkeeping. I thus leave open 
the possibility of more coercions as PlCO gets used in practice. 


5.9 The S KPUSH rule 


E be H : a:\rre\K-, A; H' A = Ai,A 2 n = |A 2 | 
k = Tla:\ rre \K, A. H'a 
a = Tr(A 2 [r/a][V’/dom(Ai)]). H't 
a' = ’n(A^? 7 ^[^/dom(Ai)]). H'¥ 

E; Rel(r) bo V ■ <* ~ o' 

E; Rel(r) h^ ec r' : a : Re (k 

Vi, 7 i = build_kpush_co((ft)@(nths (res n 77)); ip x .,.*_i) 
Vi, V’i = cast_kpush_arg(' 0 j; 7,) 

H —> k' E alt 

E; T I5 case K0 (i?{r} ift) \> rjof alt —> case K0 Hip of alt 


S_KPush 


The S_ KPush rule handles the case where the scrutinee of a case expression is 
headed by a cast. As in all previous work on System FC, this push rule is the most 
intricate. However, in this dissertation, I have taken a new approach to S_KPush 
that does not require the so-called “lifting lemma” of previous work. 68 This lifting 
lemma is a generalization of the congruence property, which does not hold in PlCO 
(Section 5.8.5.3). Instead, I rely on instantiating the type of a type constant, and on 
the fact that type constant types are always closed. As the computational content 
of the S_KPush rule must actually be implemented as part of a compiler that uses 
PlCO, this (slightly) simpler statement of S_KPush may prove to be a measurable 
optimization in practice. 

A few examples can demonstrate the general idea. Firstly, note that in S_KPush, 
only the scrutinee matters; the alternatives remain the same before and after the 
reduction. With that in mind, we can see scrutinees before and after pushing in 
Figure 5.13 on the following page. 


68 See for example, Weirich et al. [105], which contains a good, detailed explication of the lifting 
lemma. 
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Original scrutinee 

Assumptions / Notes 


Pushed scrutinee 

True > (Bool) 

simple case; no universals 

( 1 ) 

True 

Just { i nt} 3 > 7 

E; T bo 7 : Maybe Int ~ Maybe b 
b: i rre |Type e T 

(2) 

Just {b} (3 > argk ((Tla:i rre |Type, 

x: Re ia. Maybe a)@(nthi 7 ))) 


MkG {Boo i } (Bool) > 7 

E; T ho 7 : G Bool ~ Gb 

(3) 


6 :, rre |Type € T 


MkG{t,y (sym (argk x 77) , (Bool) , argk 2 77), where 
h = (TI( a:i rre [Type), (c:a ~ Bool). G a)@(nthi7) 

( Pack^Booi} True MkP{ B ooi,True }) >7 S; T 7 : TI<5i. Ex Bool ~ HS 2 . Ex b (4) 
(5i = y.Re\Proxy Bool True 
S 2 = y: Re \ Proxy b (True > j 2 ) 

E; r 72 : Bool ~ b 
b: , rre |Type e T 

Pack^} {True > ri' 0 } {MkP {BooLTr ue} > hi), where 

« = ’n(/c:irreiType), (a:in-ei(x : Re |Proxy k a), ( y: Rei Proxy ka).Exk 
rj 0 = (^©(nthi (res 1 7)) 
ho = argk 770 

hi = Vo@(True True > r]' 0 ) 
hi = argk 771 


The reductions above assume the following datatypes. In Haskell: 

data Bool = False \ True 
data Maybe a = Just a \ Nothing 
data G a where 
MkG :: G Bool 
data Proxy (a :: k) — MkP 
data Ex k where 

Pack :: V (a :: k). Proxy a -7- Proxy a —* Ex k 
And in PlCO: 

E = 600/: ( 0 ), Fa/se:(0; Bool), True:(0; Bool) 

Maybe: (a:Type), Just:(x: Bei a; Maybe), Nothing:(0; Maybe) 
G:(a:Type), MkG:(c:a ~ Bool; G) 

Proxy:(k : Type, a : /c), MkP:(0; Proxy) 

Ex:(/c:Type), Pack:(a:\ rre \k, x: Re \Proxy k a, y: Re \Proxy k a; Ex) 

Figure 5.13: Examples of S_KPush 
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build_kpush_co( 7 ; 0) = 7 

build_kpush_co(7; ip, r) = let c := build_kpush_co(7; ip) in 

c@(t ~ a rgk c T > argk c) 

build_kpush_co(7; ip, {r}) = let c := build_kpush_co(7; ip) in 
c@{t ~argk c t > argk c} 

build_kpush_co(7; ip, rj) = let c := build_kpush_co(7; V>) in 

c@(rj, sym (argk x c) 9 77 9 argk 2 c) 

cast_kpush_arg(T;7) = r > argk 7 
cast_kpush_arg({T};7) = {r > argk7} 

cast_kpush_arg(7; 77) = sym (argk x 77) , 7 9 argk 2 77 

Figure 5.14: Helper functions implementing S_KPush 


Example ( 1 ) In this example, there are no universals of the type in question (Bool), 
and so “pushing” is extraordinarily simple: just drop the coercion. We can see this 
in terms of S_KPush in that both r and ip are empty. Note that if we had a non¬ 
reflexive coercion in the scrutinee—that is, if the scrutinee were, say, True > 7 with 
E; T 7 : Bool ~ a —the case expression would not be well typed. Rule Ty_Case 
requires the type of a scrutinee to be of the form TIA. Ha. The type a does not 
have this form, and so such a scrutinee is disallowed. Also note that we cannot have 
True > 7 with E; T bo 7 : Bool ~ Int due to the consistency lemma (Section 5.10). 

Example ( 2 ) This is the simplest non-trivial example. We need to push a coercion 
7 proving Maybe Int ~ Maybe b into Justyi nt y 3. This coerced scrutinee has type 
Maybe 6 ; the pushed scrutinee must have the same type. We thus know it must start 
with Justly. The only challenge left is to cast the argument, 3, with a coercion that 
proves Int ~ b. We will always be able to extract this coercion from the coercion 
casting the scrutinee, 7 . But how, in general? 

The coercion needed to cast each (existential) argument to a constructor must 
surely depend on the type of the constructor. Previous versions of System FC did 
a transformation on this type to produce the coercion. In this work, I instantiate 
the type using the @ operator (Section 5. 8 . 6 . 2) via the helper metatheory functions 
build_kpush_co and cast_kpush_arg, presented in Figure 5.14. 

In the present case—pushing a coercion into Just : ’na:i rre |Type, x: Re |3. Maybe a — 
we take JusTs type and instantiate a by the coercion nth! 7 , which proves Int ~ b. 
We are thus left with a coercion that proves 

(Tlx: Re |/nt. Maybe Int) ~ (TLx: Re \b. Maybe b). 
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b 


sym (argk, r]) 


Bool 


(Bool) 

Bool < - Bool 

argk 2 rj 


Figure 5.15: “Casting” a coercion in Example (3) 


Then, all we have to do is use argk to extract the coercion proving Int ~ b and we 
can use it to cast 3. 

Seeing the above action in the definition for S_KPush may be challenging. Let’s 
take another look, focusing on the metavariables in the definition of the rule (presented 
in Figure 5.7 on page 102). The type o is the type of the underlying (uncoerced) 
scrutinee, and o' is the type of the coerced scrutinee. In our example, we have 
o = Maybe Int and o' = Maybe b. Note that neither of these are Tl-types, and thus 
the telescope A 2 from the rule is empty, with n — 0 . The k metavariable in the rule 
is the type of Just , above. The coercion we are building is the one to cast the first 
argument, that is, 71 . The second argument to build_kpush_co is a list of all previous 
existential arguments, but in our case, there are no previous arguments, so this fist is 
empty. We thus have 71 = build_kpush_co((/t)@(nthi 7 ); 0). 69 We can see from the 
definition of build_kpush_co that the function just returns its first argument when 
its second argument is empty, and so we get 71 = <T)@(nth| 7 ) as desired. The use 
of cast_kpush_arg is to apply the right argk form (Section 5. 8 .6.1), depending on 
whether we are casting a type or “casting” a coercion. 

We focus on understanding cast_kpush_arg on the next example. 

Example (3) The datatype G is a simple-as-they-come GADT. In this example, 
we cast MkG :: G Bool to have type G b (for some type variable b). The action in 
S_KPush here is actually quite similar to the previous case, because MkG is quite 
similar to Just: both take one argument, whose type depends on the one universal 
parameter. The difference here is that MkC s argument is a coercion, whereas Just's is 
a type. We thus cannot use argk in exactly the same way as before, instead requiring 
argk| and argk 2 , as diagrammed in Figure 5.15. In this example, two of the steps in 
the diagram are redundant, but they will not be, in general. It can be convenient to 
think of constructions such as this as “casting” a coercion—that is, taking the coercion 
(Bool) and changing it to connect b with Bool. Indeed, prior work [105] even used a 
special notation for this: 7 > rji ~ 772 , but I find it clearer to avoid the sugar. 

69 Technically, we should write res 0 7, because the superscript in res coercions is part of the 
language, not the metatheory. However, a res 0 coercion is a no-op, so I leave it out here for simplicity. 
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Example (4) Having warmed ourselves up on the simpler examples above, Example 
(4) demonstrates the full complexity of S_KPush, including dependent existential 
arguments and an unsaturated scrutinee. We’ll take these complications one at a time. 

Having dependent existentials motivates the intricacies of build_kpush_co. Since 
the pushed-in cast changes universal arguments (unless it’s reflexive), we need to cast 
existential arguments that may be dependent on the universals. However, if a later 
existential argument is dependent upon an earlier one and we change the earlier one, 
we must also change that later one. In this example, the first existential argument 
(instantiated to True) depends on the universal argument (instantiated to Bool), and 
the second existential depends on the first. The first existential is cast by rj' 0 and thus 
the second must be cast by r( x , which essentially replaces the occurrence of True in the 
type of the applied MkP constructor with True > r]' 0 , using a coherence coercion built 
with fa. Indeed, this is the whole point of build_kpush_co —using coherence to alter 
the types of later existentials depending on earlier ones. Here is the critical correctness 
property of build_kpush_co: 

Lemma (Correctness of build_kpush_co [Lemma C.45]). 

Assume E; T bev ^ : A[r/a], and let 7 * = build_kpush_co( 77 ; ip 1 j_ x ) and -0' — 
cast_kpush_arg('0 i ; 7 j). //E;Rel(T) ly 0 7 : (HA.cr)[r/a] ~ (HA. a)\f'fa\ : , then: 

1. E;Rel(T) bo build_kpush_co( 77 ;0) : cr[r/a]['0/dom(A)] ~ o[r'/a\[$' /dom(A)] 

2 . E; T bev ? : A[r'/a] 

This lemma is phrased in terms of bev! that relation includes the same elements as bee 
but allows induction from right-to-left instead of the usual left-to-right. The 77 in the 
lemma statement relates the type of a constructor to itself, but with the universals 
instantiated with potentially different concrete arguments. These instantiations come 
directly from the coercion being pushed into the scrutinee, by way of nth. (Note that 
the ’n quantifiers in the type of 77 above are not a consequence of the possibility of 
unsaturation; instead, these are the existentials of the data constructor.) The lemma 
concludes that the resulting coercion relates the instantiated coercion (that is, the 
one built by build_kpush_co) to itself, with substitutions for both the universals and 
some existentials. Along the way, it also asserts the validity of the cast existentials, 
via the bev result. 

The remaining detail of Example (4) is its unsaturation. This is handled more 
simply by a res coercion (Section 5. 8 . 6 .2), which looks through binders to relate the 
bodies of two abstract types. Indeed, S_KPush is the reason that the res coercion 
exists at all, though it is not a burden to support in the metatheory. 

5.10 Metatheory: Consistency 

Broadly speaking, the type safety proof proceeds along lines well established by prior 
work [11, 31, 106]. Indeed, the only challenge in proving the preservation theorem 
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Type compatibility 


T\ is not a value 
n oc t 2 

r 2 is not a value 
m oc t 2 


C_ Non Value 1 
C_NonValue2 


---C_TyCon 

-0 OC 0 


rocr' 

II a: p K. t oc II a\ p K'. r' 


C_PiTy 


IIc: 0 . t oc ITc:^. r' 


C_PiCo 


A<5. t oc\8'. t' 


C_Lam 


Figure 5.16: Type compatibility 

is in dealing with S_KPush. The tricky bit is all in proving the correctness of 
build_kpush_co; see Section 5.9. Otherwise, the proof of preservation is as expected. 

On the other hand, progress is a challenge, as it has been in previous proofs of 
type safety of System FC. We proceed, as before, by proving consistency and then 
using that to prove progress. (The definition for oc is in the next subsection.) 

Lemma (Consistency [Lemma C.74]). If T contains only irrelevant type variable 
bindings and E; F 7 : t\ ~ r 2 then T\ oc t 2 . 

We restrict T not to have any coercion variables bound. Otherwise, a coercion 
assumption might relate, say, Int and Bool and we would be unable to prove consistency. 
As consistency is needed only during the progress proof, this restriction does not pose 
a problem. 


5.10.1 Compatibility 

The statement of consistency depends on the T\ oc t 2 relation (pronounced “ti is 
compatible with t 2 ”), as given in Figure 5.16. The goal of compatibility is to relate 
any two values (as defined in Section 5.7.1) that have the same head; non-values 
are compatible with everything. Note, in particular, in C_TyCon, that we care 
only that the two H are the same. The universals (r/r') and existentials (ip/if) are 
allowed to differ. The one exception to this general scheme is in the C_PiTy rule, 
where we require the bodies t/t' also to be compatible. This is necessary because 
irrelevant binders are erased, and we must thus be sure that any exposed types are 
also compatible. 
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Consistency is used in the progress proof mainly in order to establish the typing 
premises of the push rules (Section 5.7.4). A representative example is in the case 
when we are trying to show that an application 77 t 2 is either a value or can step (it is 
clearly not a coerced value; recall the statement of the progress theorem from Section 
5.7). The induction hypothesis tells us that 77 is a value, a coerced value, or can step. 
If it can step, we are done by S_App_Cong. If 77 is a value, we can determine that 
it is a A-abstraction and thus we can do /^-reduction. The remaining case is when 77 is 
a coerced value v > 7 . We need to be able to show that 7 relates two 11-types in order 
to use S_PushRel. The right-hand type must be a Il-type because it is the function 
in an application. But the only way we can show that the left-hand type is a Il-type 
is by appealing to consistency. 

We know, at this point, that the type being coerced is a value; thus its type is also 
a value (Lemma C.76, also introduced in Section 5.7.1). At this point, now that we 
know that both types involved in the type of the coercion 7 are values, compatibility 
becomes a much stronger definition, allowing us to conclude that if the types are 
compatible and if one is a Il-type, the other must surely also be a Il-type. Because we 
can rule out non-values in the places where we wish to invoke the consistency lemma, 
the flexibility around non-values does not get in our way. 

5.10.2 The parallel rewrite relation 

To prove consistency, I (following prior work) define a parallel rewrite relation, written 
t 1 t 2 , and show that this relation includes pairs of compatible types only. A small 
wrinkle with this definition is that the rewrite relation works over only types whose 
coercions have been erased, as per the |_-J operation, initially introduced along with 
coherence coercions in Section 5.8.3. The operation, as you may recall, removes all 
casts from a type, and replaces coercion arguments with an uninformative •. Stripping 
out casts and coercions is important in the rewrite relation; if the rewrite relation 
considered these features, the language would lose its coherence property. Going 
forward, I use a convention where all types written as being related by have had 
their coercions erased. 

The rewrite relation -w appears in Figure 5.17 on the next page and Figure 5.18 
on page 126. Following conventions in the rewriting literature, I write 77 T$ t 2 to 
mean that 77 73 and t 2 73, and I write 77 t 2 to mean the reflexive, transitive 

closure of 

Note the Beta rules, which work over only unmatchable applications 777 . This 
fact allows us to conclude that matchable applications r ih never undergo /^-reduction, 
in turn allowing us to prove that the left and right coercions are sound. 


124 



Type parallel reduction, over erased types 


6 -^ 6 ' t 

A 5 . t -w \ 6 '. 


absurd • r absurd • r' 


case K t of 7 T —y g case K / r' of 71 


(Aa:i rre |K. ti)_{t 2 } t [[ t ^/ o \ 


R BetaIrrel 


case K 0 of alt Tq 0 • 
no alternative in alt matches H 


case K ih r } -0 of alt <7' 


fix (AaiReiK. cr) a'[fix (Aa:R e |/d. cr')/a 


Figure 5.17: Parallel reduction over erased types 
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8 ^ 8 '\ Parallel reduction of binders 


K tv 


a: p K a: p K' 


R_TyBinder 


t t' Hi k[ k 2 k ' 2 cr -w ct' 

• :t a #:r / «irsX cr' 


R_CoBinder 


7 7 ' | “Reduction” of erased coercion 


- R ErasedCo 

• -w • 


Figure 5.18: Parallel reduction auxiliary relations 

5.10.2.1 Substitution 

The relation is almost a non-deterministic, strong version of normal reduction 
(E; T li t — > t'). In all the congruence forms (toward the top of Figure 5.17 on the 
previous page), the relation definition recurs in every component, as necessary to 
support the following lemma: 

Lemma (Parallel reduction substitution in parallel [Lemma C.51]). Assume ip t/j . 

1. If T\ t 2 , then n[if/z] r 2 [ip / z\. 

2. If Si S 2 , then 8 i[if/z] S 2 [ip'/z\. 

Note that all of the reductions are single-step. 

Beyond the congruence rules, the rewrite relation includes parallel variants of 
the reduction rules from the normal step relation, toward the bottom of the figure. 
Note that these allow the components of a type to step as the reduction happens, as 
required for the local diamond lemma needed to prove confluence. 

5.10.2.2 Confluence 

This reduction relation is confluent (that is, has the Church-Rosser property). I prove 
this by proving a local diamond lemma: 

Lemma (Local diamond [Lemma C.54]). 

1. If r 0 t i and t 0 t 2) then there exists t 3 such that n t 3 t 2 . 

2. If <5 0 <5i and 8 0 8 2 , then there exists 83 such that <5i 83 8 2 . 

The proof of this lemma reasons by induction on the structure of Tq/ 8 q and makes 
heavy use of the substitution lemma above. It is not otherwise challenging. The local 
diamond lemma implies confluence. 
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5.10.3 Completeness of the rewrite relation 

Having written a confluent rewrite relation, we must also connect this relation to our 
equality relation. This is done via the following lemma: 

Lemma (Completeness of type reduction [Lemma C.62]). If E; T 1 ^ 0 7 : 7*1 2 t 2 

and c # 7 /or eren/ c:/ e T, then: 

T There exists some erased type e such that |_TiJ e L r 2_|- 

2. There exists some erased type e such that [ftij e *<-~ [« 2 j • 

Both the statement and proof of this lemma are rather more challenging than 
the previous ones. The proof proceeds by induction on the typing derivation. It is 
necessary in the proof to use the induction hypothesis on a premise where the context 
T is extended with a coercion variable (say, in the case for Co_PlCo). Thus, even 
though we will only use this lemma in a context with no coercion variables, we must 
strengthen the induction hypothesis to allow for coercion variables. Critically, though, 
we restrict how all coercion variables in the context can appear in 7 , according to the 
definition of #, introduced in Section 5. 8 .5.2. This restriction allows us to skip the 
impossible Co_Var case while still allowing induction in the Co_PlCo case. 

The definition of c # 7 allows c to appear in the types related by a coherence ~ 
coercion. Happily, in the Co_Coherence case (when proving clause 1 of the lemma), 
we do not need to use the induction hypothesis, as a premise of Co_Coherence 
states that the erased types are, in fact, already equal. It is for precisely this reason 
that c # 7 can allow c in the types in a coherence coercion. 

We also see that the statement of the completeness lemma requires us to prove 
both that the types are joinable under -w and also that the kinds are. Otherwise, there 
would be no way to handle the kind case. 

Having strengthened the induction hypothesis appropriately, the actual proof is not 
too hard. The case for transitivity uses confluence—this is the only place confluence is 
used. The decomposition forms use the fact that when a value type reduces under -w, 
the reduct has to have the same shape as the redex, with individual components in the 
redex reducing to those same components in the reduct. To deal with step, we must 
consider the different possibilities given by the E; T ^ r — > r' relation. The proper 
reduction rules all have analogues in the congruence rules all follow from the 
induction hypothesis, and the push rules cause no change to a type with its coercions 
erased. To prove that the kinds are joinable, we must rely heavily on the deterministic 
nature of the typing relation, but there are no other undue complications. 

5.10.4 From completeness to consistency 

Having established the relationship between E; T 1 ^ 0 7 : / and joinability with respect 
to the rewrite relation, we must only show that the rewrite relation relates compatible 
types. Here are the key lemmas: 
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Lemma (Joinable types are consistent [Lemma C.72]). If e 3 e 2 , then 

€1 oc e 2 . 

Lemma (Erasure/consistency [Lemma C.73]). If |_Ti J oc |_t 2 J, then T\ oc t 2 . 

Other than some care needed around irrelevant abstractions (which cause recursion 
in the rules defining oc), these lemmas are not hard to prove. 

With all the groundwork laid, we can now conclude our consistency lemma, stated 
near the top of this section. 

5.10.5 Related consistency proofs 

There are a few aspects of the consistency proof where it may be helpful to highlight 
the differences between my proof here and those in prior work. The comments below 
dispute other, published proofs of consistency. The authors of these proofs have 
conceded to me in private communication that their proofs were incorrect and do not 
disagree with my assertions here. 

5 . 10 . 5.1 Non-linear, non-terminating rewrite systems are not confluent 

As described in some detail by Eisenberg et al. [32], non-terminating rewrite systems 
with non-linear left-hand sides are not confluent. We can easily see that the rewrite 
relation is not terminating. In this presentation, however, its “left-hand side” is 
linear. Breaking from previous work, I have phrased type families in PlCO as A- 
expressions that use case; thus the parallel to rewrite systems is not as apparent as 
in previous work. In the context of my work here, a non-linear left-hand side would 
look like a primitive equality check, as further explored in Section 5.13.2. Because the 
formalization of PlCO that I am presenting does not contain this equality operator, I 
avoid the non-confluence problem described by Eisenberg et al. [32], 

Nevertheless, promising new work in the term-rewriting community [50] suggests 
that there is a way to prove consistency without confluence even after adding an 
equality check. I leave it as future work to reconcile the approach here with the recent 
result cited above. 

5 . 10 . 5.2 The proof of consistency by Weirich et al. [ 105 ] is wrong 

The type system presented in my prior work [105] is very similar to PlCO, although 
without dependency. Its treatment of Co_PlCo is subtly different, however. Although 
there are numerous changes in how the syntax is structured, that work effectively 
loosens the definition of c # 7 to allow c anywhere in a coherence coercion (ti t 2 ). 
In contrast, PlCO allows c only in t\ or r 2 , but not in rj. When armed with the kind 
coercion (identical in PlCO to the version in the previous work), this allows us to 
violate a key lemma used to prove consistency. Here is the counterexample coercion, 
translated into PlCO: 
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7 = n c:((lnt), (Bool)), kind (3 (3 > c)) 

In the body of the abstraction, the coercion variable c has type Int ~ Bool. We 
can use a coherence coercion to relate 3 and 3 > c; their kinds are also related by c. 
We can then extract the kinds of the types related by the coherence coercion. Putting 
it all together yields this fact: 

S; 0 7 : (nc:/nt ~ Bool. Int ) ~ (IIc:/nt ~ Bool. Bool ) 

The problem is that we can see that no rewrite relation will join the two types related 
by 7 . Because the prior work’s type system permits 7 , its consistency proof must 
be wrong. (PlCO rules out 7 for using c in an illegal spot—the kind coercion in the 
subscript for «.) Note that the language in that work might indeed be consistent (I 
have no counterexample to consistency), but its consistency surely cannot be proved 
via the use of a rewrite relation in the way presented in that paper. 

5.10.5.3 A one-variable version of Co_PiTy simplifies the consistency 
proof 

Weirich et al.’s language differs along a different dimension, using three binders instead 
of one in its version of Co_PiTy. (See discussion in Section 5 .8. 5 . 1 .) Apart from 
the awkwardness of needing extra variable names, the three-binder approach poses 
another problem: it introduces a coercion variable into the context. Unlike for their 
Co_PlCo, Weirich et al. do not introduce a coercion variable restriction for this 
coercion variable, as it is always a proof of equality between two variables. This extra 
coercion variable cannot imperil consistency. To prove this in the consistency proof, 
Weirich et al. employ a notion of “Good” contexts, which must be threaded through 
their proofs. My one-variable version, with no bound coercion variable, avoids this 
complication. 

5 . 10 . 5.4 The proof of consistency by Gundry [ 37 ] is wrong 

Gundry, in his thesis, takes a very different approach to proving consistency of 
his evidence language, also closely related to PlCO. He sets up, essentially, a step- 
indexed logical relation and uses it to consider only closed coercions; when, say, a 
coercion variable is added to the context, Gundry quantifies over all possible closing 
substitutions. 

A key property of Gundry’s logical relation is transitivity. Yet, in his proof of 
transitivity, the indices do not work out. Gundry was not able to spot a straightforward 
solution, and in unpublished work, Weirich also tackled this problem and failed. Neither 
Gundry nor Weirich (nor I) have a proof that the step-indexed logical relation approach 
is not able to work, but no one has been able to finish the proof, either. 

The failure of this approach is disappointing, because Gundry’s evidence language 
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does not have the coercion variable restriction inherent in Pico’s Co_PlCo rule. 
Gundry’s language thus allows more coercions than does PlCO. 

Can a System-FC-like language be proven consistent without a coercion variable 
restriction on its analogue of Co_PlCo? My personal belief is “yes”—given that I 
believe such a language is, in fact, consistent—but researchers have yet to show it. 

5.11 Metatheory: Type erasure 

A critical property of any intermediate language used to compile Haskell is its ability to 
support type erasure. Haskell takes pride in erasing all of its complicated, helpful types 
before runtime, and the intermediate language must show that this is possible. PlCO 
achieves this goal through its relevance annotations, where irrelevant abstractions 
and applications can be erased. In previous, non-dependent intermediate languages 
for Haskell, irrelevant abstractions and applications were also erased, but these were 
easier to spot, as they dealt with types instead of terms. In PlCO, types and terms 
are indistinguishable, so we are required to use relevance annotations. 

I prove the type erasure property via defining an untyped A-calculus with an 
operational semantics, defining an erasure operation that translates from PlCO to the 
untyped calculus, and proving a simulation property between the two languages. 

5.11.1 The untyped A-calculus 

The definition of our erased calculus appears in Figure 5.19 on the following page. It 
is an untyped A-calculus with datatypes (allowing for default patterns) and fix. The 
language also contains two fixed constants, ’n and II, here only to have something for 
n-types to erase to. 

The calculus also supports “coercion abstraction” via its A».e and e • forms. The 
existence of these forms mean that coercion abstractions are not fully erased. We can 
see why this must be so in the following example: let r = A c:lnt ~ Bool, not (3 > c). 
The type r is a valid PlCO type. We do not have to worry about the nonsense in the 
body of the abstraction because consistency guarantees that we will never be able 
to apply t to a (closed) coercion. As an abstraction, r is a value and a normal form. 
However, if our type erasure operation dropped coercion abstractions, then disaster 
would strike. The erased expression would be not 3, which is surely stuck. We thus 
retain coercion abstractions and applications, while dropping the coercions themselves 
by rewriting all coercions with the uninformative •. 

What has now happened to our claim of type erasure? Coercions exist only to 
alter types, so have we kept some meddlesome vestige of types around? In a sense, 
yes, we have kept some type information around until runtime. However, two critical 
facts mean that this retention does not cause harm: 

• Coercion applications contain no information, and therefore can be represented 
by precisely 0 bits. Indeed, this is how coercions are currently compiled in GHC, 
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by using an unboxed representation that is 0 bits wide. Thus, no memory is 
taken up at runtime. 

• The coercion abstractions are not, in fact, meddlesome. The way in which 
coercion abstractions could cause harm at runtime is by causing a program to be 
a value when the user is not expecting it. For example, if a compiler translated 
the Haskell program 1 + 2 into the expression A».l + 2, then we would never 
get 3. I thus make this claim: no Haskell program ever evaluates to a coercion 
abstraction. This claim is properly a property of the type inference / elaboration 
algorithm and so is deferred until Section 6.10.2. 

One may wonder why PlCO needs coercion abstractions at all. I can provide two 
reasons: to preserve the simplified treatment of case that does not bind variables, and 
in order to enable floating. An optimizer may decide to common up two branches of a 
case expression (i.e., float the branches out), both of which bind the same coercion 
variable. If there were no coercion abstraction form, this would be impossible. It is a 
correctness property of the optimizer (well beyond the scope of this dissertation) to 
make sure that the floated coercion abstraction does not halt evaluation prematurely. 

5.11.2 Simulation 

Here is the simulation property we seek: 

Theorem (Type erasure [Theorem C.83]). //S; T b r —)• r', then either [[rJJ —>• [[r'JJ 
or ffj = U/J • 

Note that the untyped language might step once or not at all. For example, when 
PlCO steps by a push rule, the untyped language does not step. The proof of this 
theorem is very straightforward. 

5.11.3 Types do not prevent evaluation 

Proving only that the erased calculus simulates PlCO is not quite enough, as it still 
might be possible that an expression in the erased calculus can step even though 
the PlCO type from which it was derived is a normal form. The property we need is 
embodied in this theorem: 

Theorem (Types do not prevent evaluation [Theorem C.86]). Suppose E; F r : k 
and T has only irrelevant variable bindings. If [[rJJ — e', then E; T lj r — >■ r' and 
either [[t'JJ = e' or [[t'J] = [[tJJ. 

This theorem would be false if PlCO did not step under irrelevant binders, for 
example. 

The proof depends on both the progress theorem and the type erasure (simulation) 
theorem above, as well as this key lemma: 
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Lemma (Expression redexes [Lemma C.84]). If [[tJJ is not an expression value, then 
t is neither a value nor a coerced value. 

This lemma is straightforward to prove inductively on the structure of r, and then 
the proof of the theorem above simply stitches together the pieces. 

5.12 Design decisions 

In the course of designing PlCO, I have had to make quite a number of design decisions. 
Some of these are forced by external constraints (such as the need for two II-forms), 
but others have been relatively free choices. In this section, I revisit some of these 
decisions and try to motivate why I have built PlCO in the way that I have. It is 
my hope that this section will empower readers who wish to extend or alter PlCO to 
understand its design better. 

5.12.1 Coercions are not types 

One alternative I considered was to make a coercion 7 a possible production of a type 
t. This would allow, for example, the form T\ T 2 to encompass both type application 
and coercion application. Going down this route, propositions would also have to 
become kinds k, and we would have a rule such as 

E; T bo 7 : <f> 

——— -— Ty Coercion 

£;P^7 :</> 

This alternative design does not cause trouble with type safety, because we are injecting 
the safe coercions into the unsafe types. The other way around—injecting potentially 
non-terminating types into coercions—would lead to chaos. 

This injection would simplify aspects of the grammar and rules. For example, the 
argk, and argk 2 coercions could be rewritten in terms of argk and nth. 

In the end, I decided against this design because it simply moves the complexity 
around. Instead of the syntactic complexity inherent in Pico’s actual design, this 
injection would cause complexity in needing to rule out the presence of coercions in 
various places where they would not appear. For example, the scrutinee of a case can 
never be a coercion, and there is no good way to define what [[ 7 JJ should be. The 
design I chose adds a little syntactic overhead to avoid these thorny proof obligations, 
and that seems to be a win. 

5.12.2 Putting braces around irrelevant arguments 

A similar design decision was to put braces around irrelevant arguments. The syntactic 
distinction between relevant arguments and irrelevant ones is not necessary for syntax- 
directedness, because we can always look up the type of the function to see whether 
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we should consider the type application to be relevant or irrelevant. Yet putting this 
distinction directly in the syntax makes certain parts of the metatheory cleaner, when 
relevant and irrelevant applications are treated separately. Marking relevance in the 
syntax also allows us to define an erasure operation that is not type-directed. 

5.12.3 Including types’ kinds in propositions 

Given that we can always extract a type’s kind from the type, why is it necessary 
to mark all propositions with the types’ kinds, as in k< ^ k ' 2 t 2 ? (Recall that all 
propositions in PlCO are so marked, even though the kinds are frequently elided in the 
typesetting.) Once again, having details present directly in the syntax of propositions 
is more convenient than having those details implicit in the kinds of types. In this 
case, the kinds are necessary when defining argk, and argk 2 . When proving the 
completeness of the rewrite relation (Section 5.10.3), we must be able to show that the 
kinds of the two types related by a coercion are joinable. Without having the kinds in 
the types erased of coercions (that is, in the output of |_-J), this is not provable. 

An alternative here would be to have the erased language maintain the kinds 
but to omit them from PlCO proper, but that makes erasure type-directed and more 
challenging. It seems simpler (and rather less error-prone) once again to make the 
syntax more ornate and the proofs shorter. 

5.13 Extensions 

I conclude this chapter by considering several extensions one might want to make to 
PlCO to support a few more features of Haskell. 

5.13.1 let 

Haskell allows binding variables with let, and it would be convenient to do so in 
PlCO as well. We shall consider the non-recursive case first and then move on to the 
complexities of letrec. Below, flouting Haskell convention, I use let to refer exclusively 
to the non-recursive case and use letrec when considering recursive bindings. 

Non-recursive let would be very easy to incorporate. At first blush, we could 
consider let as a derived form, much as described in the literature [77, Section 11.5], 
replacing let (x : k) rina with (\x: Re \K. a) r. However, doing so would make 
optimizations harder: with the explicit let form, the optimizer can know the value of x 
in a; this connection is lost with the applied A-expression. Nevertheless, adding let as 
a new proper type form would be straightforward. We could additionally incorporate 
the ability to bind a coercion variable proving that, say, x ~ r in a. We would also add 
a new rule to the operational semantics expanding out all let definitions directly; an 
implementation may wish to optimize this, however. The only real challenge we would 
run into is adding a congruence coercion for let, which would share the complications 
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of the other binding forms (see Section 5.8.5.1). The designer of this extension could 
choose, however, to omit the congruence coercion for let, as the coercion is not strictly 
necessary. 

Recursive letrec has all of the complexities above, along with the challenge of 
being recursive. In an expression such as letrec (x : k) := r in a, we would not be able 
to bind a coercion variable witnessing the equality between x and r, as that would 
bring us into the realm of very dependent types [42], Even ignoring that complication, 
we may also wish to consider the operational semantics of letrec. To my surprise, I 
am unable to find a published account of an operational semantics that deals with 
letrec, other than my own unproven version [26]. I can imagine rewriting a letrec 
to a form where each recursive occurrence of a variable is replaced with a copy of 
the entire letrec. I believe this would hold together, though I have not worked out 
the details. I do not wish to begin to imagine what a congruence coercion for letrec 
would look like. 

Despite these challenges, I do think an implemented version of PlCO could accom¬ 
modate a primitive letrec rather easily, as the implementation of the language in an 
optimizing compiler would not have to include the operational semantics rules verbatim. 
Indeed, despite many published versions of the operational semantics of System FC 
(e.g., [87]), GHC does not currently implement these rules directly. In a similar fashion, 
an implementation of PlCO would not need to include the hideously inefficient version 
of letrec sketched above but could use existing techniques to implement recursion. 

Given that PlCO incorporates general recursion via fix, adding such constructs 
should not imperil type safety. 

5.13.2 A primitive equality check 

Haskell also supports non-linear patterns in its type families, as canonically embodied 
by this type function: 

type family Equals x y where 
Equals a a = ’True 
Equals a b = ’ False 

The Equals type family effectively compares its two arguments. If they are identical 
(reducing other type families as possible and necessary), Equals returns True. On the 
other hand, if the two arguments are apart, in the sense described by Eisenberg et al. 
[32], 70 Equals reduces to False. If the arguments are neither identical nor apart, the 
call cannot reduce. 

Equals cannot be represented in PlCO as described in this chapter; no typing rule 
has a notion of apartness built into it. Thus we need a new primitive if we are to 

70 Briefly, two types are apart if there is no possibility of a coercion between them. Or, rather, it is 
a conservative approximation of non-coercibility, as non-coercibility is undecidable. 
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E; T hf y Ti : K 


S;T hfy t 2 : K 


E; T ht y equals 77 t 2 : Bool 

_ S; r hty t : /c _ 

E; T hj 0 axEquals r : equals rr~ True 

r hty Ti : /c E; r hty t 2 : « 

apart(ri;r 2 ) 

E; T h^ 0 ax Apart Ti t 2 : equals 77 t 2 ~ False 

E ; T ^ n —► rf 


Ty_ Equals 
Co_AxEquals 

Co AxApart 


E; T h equals Ti t 2 - 
E; T ^ r 2 - 
E; T hi equals 77 t 2 - 


> equals r[ t 2 


> equals 77 T2 


E; T ^ equals v v - 

_ Vl ± V2 

E; T hi equals v\ v 2 - 


S_Equals_Cong1 


S_Equals_Cong2 


S_EqTrue 


^ , S EqFalse 
>■ False 


Figure 5.20: Typing rules for primitive equality 


compile Equals. Actually, we need three: 

t ::= ... | equals Ti r 2 
7 ::= ... | axEquals r | axApart n t 2 

The typing rules appear in Figure 5.20. Other than the new coercions axEquals 
and axApart, these rules might be what one would expect: the equals form evaluates 
its two arguments and then tests for equality. However, just having this evaluation 
behavior (without the two new coercions) is not quite enough to emulate Haskell’s 
Equals: they cannot handle the case where Equals a a reduces to True, where a is 
locally bound type variable. In Haskell, the equality condition arising from a non-linear 
use of a variable in a pattern does not require that the arguments be reduced to any 
normal form; we thus have to handle this possibility in PlCO. The same is true for the 
axApart coercion, necessary to handle the case (like equals Int (Maybe a), where a is 
a local type variable) where the arguments are demonstrably apart but not normal 
forms. 

The typing rules above cause a challenge in proving the completeness of the rewrite 
relation (Section 5.10.3). To prove completeness for Co_AxEquals, we would need 
to show that equals rr eventually reduces to True, but that requires termination. 
To prove completeness for Co_A xApart, we would need to show that 77 and t 2 
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reduce to distinct values whenever apart(Ti; t 2 ). This also requires termination, in 
addition to certain properties of apartness. Since PlCO is non-terminating, this direct 
approach is hopeless. Instead, we might add new rules to the rewrite relation to deal 
with these cases, but that moves the burden to the proof of the local diamond lemma 
(Section 5.10.2.2). Eisenberg et al. [32] explore this territory in some detail, but with an 
unsatisfying conclusion: that work assumes termination in order to get the consistency 
proof to go through. 

As mentioned above, it is possible that recent work in this area by Kahrs and 
Smith [50] gives us a way to include equals without losing consistency, but I have yet 
to formally connect my work to theirs. 

5.13.3 Splitting type applications 

Haskell type families permit an unusual operation I will call splitting: 

type family Split x where 
Split (a b ) = ’ Just ’(a, b ) 

Split other = ’Nothing 

The Split function, inferred to have Haskell kind V k x k 2 . k 2 —> Maybe (/cy —>• 
k 2 , /c 1 ), can detect a type application. It will return Just if it sees 10 Int but Nothing 
if it sees Bool. This function cannot be encoded into PlCO as it stands. 71 We instead 
must add a new primitive, split. 

At its most basic, a split expression would look like this: split r into ay or o 2 . The 
idea is that if r is a type application T\t 2 , then the split expression reduces to 
(applied to some details of r); otherwise, the expression reduces to o 2 . The result kind 
of t 1 is known: it is the type of T. However, the argument kind of T\ is not apparent 
and thus must be passed to ay. The type o x would thus be 


IJapirreiType, b 1 : Kti ('ILc: Ra a 1 . k), b 2 : Re |Oi, c:t ~ b 2 . k 2 

where k is the kind of the scrutinee r and k 2 is the result kind. Note the TI in the 
type of bi, meaning that we can break apart only matchable applications. This is a 
good thing, because we would not want to be able to separate arbitrary functions 
from their arguments to inspect one or the other. In this formulation, the kind of o 2 
would just be k 2 . 

Unfortunately, this “most basic” version does not quite cut it. The problem is 
that the scrutinee t might also be T\ {t 2 } or T172, and thus the split form would 
really need four branches (including one for the default, atomic case). Each case would 
need its own rule in the operational semantics. We would also need a push rule in 
case a coercion is in the way of examining a type application. The parallel rewrite 

71 Other type families, as long as their left-hand sides do not repeat variables, can be desugared 
into Pico, by adapting work by Augustsson [2]. 
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relation would need to be extended as well, with analogues to all the new rules in the 
operational semantics. In the end, it seems split is not paying its way, and so I have 
kept it out of this presentation. Despite this omission, I do believe it would not be a 
technical challenge to add, should this feature prove necessary. 

5.13.4 Levity polymorphism 

In version 8, GHC supports levity polymorphism [28]. The idea is embodied in the 
following mutually recursive definitions: 

data Unary Rep = PtrRep \ IntRep | ... 
type RuntimeRep = [UnaryRep] 

constant TYPE :: RuntimeRep —> Type — primitive constant 
type Type = TYPE ’PtrRep 

The idea here is that instead of having one sort, Type, the language would have a 
family of sorts, all headed by TYPE and indexed by an element of type RuntimeRep. 
At runtime, each sort corresponds to a different representation: values of a type of 
kind TYPE ’[PtrRep] are represented by pointers to potentially thunked data, whereas 
values of a type of kind TYPE ’[IntRep] are represented directly as machine integers. 
The use of a list to index TYPE is to support GHC’s unboxed tuples , which group 
together values that would be passed in several registers; see a more detailed description 
in my concurrent work [28]. 

As described in my concurrent work (and too much of a diversion here to repeat 
in detail), abstracting over runtime representations must be quite restricted, lest the 
code generator be hamstrung when trying to compile code involving an unknown 
runtime representation. 

Levity polymorphism is useful in Haskell because a number of constructs are truly 
flexible in which representation they work over. Two telling examples are error and (—>■). 
Regardless of the representation of the result of a function, error is always well typed, 
and (— y) works to connect types of varying representations (like Int # —>■ Bool, where 
Int # has kind TYPE ’[IntRep] and Bool has kind Type—that is, TYPE ’[PtrRep].) 

Because levity polymorphism simply amounts to adding more sorts to a language, 
it would seem not to run into trouble with type safety. And I indeed believe this is 
true, that levity polymorphism does not threaten the type safety proof. However, it is 
very syntactically painful to add to the formalism, essentially requiring annotating 
every n with the sort of its binder. This annotation becomes necessary for precisely 
the same reasons that we must include kinds in the types of a proposition (Section 
5.12.3): we cannot prove completeness of the rewrite relation (Section 5.10.3) without 
it. 

I thus leave adding levity polymorphism as an exercise to the reader; in my attempt 
to add this feature, I encountered no real challenge other than fiddliness and lots of 
syntactic noise. 
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5.13.5 The (—»■) type constructor 

Haskell allows programmers to use the function arrow, (—>•), as a type constructor of 
kind Type —y Type —>• Type. 72 Here are two examples of how this works: 73 

— a class of categories 

class Category ( cat:: k —>■ k —>■ Type) where 
id :: V (a :: k). cat a a 

(o) :: V (a :: k) ( b :: k) (c :: k). cat b c —>• cat a b —>■ cat a c 

— the instance for (—>•) 

instance Category (—>•) where 
id x = x 

(f o g)x=f(gx) 

— a lightweight reader monad, based on (—>•) 

instance Functor ((—>•) a) where 
fmap f g x = f (g x) 
instance Applicative ((—>•) x) where 
pure x = A_ —y x 
( f<*>g ) X = f X (g x) 
instance Monad ((—») x) where 
(f^=g)x = g (fx) x 

Unfortunately, PlCO cannot, as written, easily accommodate (—>•). A non-depen- 
dent arrow is rightly seen as a degenerate form of n: the type a —> b is the same as 

n_:R e ia. b. Without introducing yet a new function type (on top of the six we already 

have) and argument syntax, it seems hard to abstract over this degenerate form of n. 

Instead, we could add (—>■) as a new primitive constant with coercions relating it 
to IT: 


H ::= 

7 ::= ... | arrow Ti t 2 


S hf c (-)•) : 0; a: Re |Type, 6: Re |Type; Type 


Tc_Arrow 


S; r hty Ti : Type S; r r 2 : Type 

E; T bo arrow n r 2 : (->) n r 2 ~ na: Re |Ti. r 2 


Co_Arrow 


The problem we are faced with at this point is consistency. Specifically, we will 
surely be unable to prove completeness of the rewrite relation (Section 5.10.3) with the 
Co _ Arrow rule. To repair the damage, we can alter the coercion erasure operation 

72 The kind of (—>) really is restricted to be Type —► Type —> Type, even though a saturated use 
of it can relate unlifted types as well. This oddity is due to be explored, among other dark corners of 
lifted vs. unlifted types, in a paper I am hoping to write in the next year. 

73 Recall that, in ((—>) x), x is the parameter that is normally written to the left of the arrow. 
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to also rewrite saturated arrow forms to be II forms, where the following equation is 
tried before other application forms: 

|_(-s-)tit 2 J = naiReiLnJ. i||| 

Now, completeness for Co_Arrow is trivial. 

The problem will last surface in the erasure/consistency lemma (Section 5.10.4), 
which states that whenever |_TiJ oc |_t 2 J, we have T\ oc t 2 . This is now plainly false. We 
must assert that arrow forms are consistent with Il-types: 


7 —r-—- C Arrow 1 

H)tit 2 oc na: Re |Ti.T 2 


rja: R eiTi.T 2 oc ( y ) T\ t 2 


C_Arrow2 


The definition of oc is used in the proof of progress, where now we must consider 
the possibility of encountering unexpected arrow types. This possibility, though, is 
dispatched by adding one clause to the canonical forms lemma: 


Lemma (Canonical form of arrow types). E; T l^ y v : (—>•) T\ t 2 

That is, no value has an arrow type, because all A-forms have Il-types instead. 
With this in hand, the progress proof should go through unimpeded. 


5.14 Conclusion 

This chapter is a full consideration of PlCO. The detail presented here is intended 
to be useful to implementors of the language and researchers interested in adapting 
PlCO to be used as the internal language for a surface language other than Haskell. 
I believe PlCO is a viable candidate as a general-purpose intermediate language for 
dependently typed surface languages. 
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Chapter 6 

Type inference and elaboration, or 
How to Bake a Pico 


Chapter 4 presents the additions to modern Haskell to make it Dependent Haskell, 
and Chapter 5 presents PlCO, the internal language to which we compile Dependent 
Haskell programs. This chapter formally relates the two languages by defining a 
type inference/elaboration algorithm, 74 Bake, checking Dependent Haskell code and 
producing a well typed PlCO program. 

At a high level, Bake is unsurprising. It simply combines the ideas of several 
pieces of prior work [33, 37, 99] and targets PlCO as its intermediate language. Despite 
its strong basis in prior work, Bake exhibits a few novelties: 

• Perhaps its biggest innovation is how it decides between dependent and non¬ 
dependent pattern matching depending on whether the algorithm is in checking 
or synthesis mode. (See also Section 6.4.) 

• It turns out that checking the annotated expression (A(x :: s) —> ...) ::Vx-> ... 
depends on whether or not the type annotation describes a dependent function. 
This came as a surprise. See Section 6.6.4. 

• The subsumption relation allows an unmatchable function to be subsumed by a 
matchable one. That is, a function expecting an unmatchable function a — > b 
can also accept a matchable one a y b. 

After presenting the elaboration algorithm, I discuss the metatheory in Section 6.8. 
This section include a soundness result that the PlCO program produced by Bake 
is well typed. It also relates Bake both to OutsideIn and the bidirectional type 
system (“System SB”) from Eisenberg et al. [33], arguing that Bake is a conservative 
extension of both. 

74 I refer to Bake variously as an elaboration algorithm, a type inference algorithm, and a type 
checking algorithm. This is appropriate, as it is all three. In general, I do not differentiate between 
these descriptors. 
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Full statements of all judgments appear in Appendix D, while theorems and 
definitions, with proofs, appear in Appendix E. 


6.1 Overview 

Bake is a bidirectional [78] constraint-generation algorithm [79]. It walks over the 
input syntax tree and generates constraints, which are later solved. It can operate in 
either a synthesis mode (when the expected type of an expression is unknown) or in 
checking mode (when the type is known). Like prior work [37, 99], I leave the details of 
the solver unspecified; any solver that obeys the properties described in Section 6.10.1 
will do. In practice, the solver will be the one currently implemented in GHC. Despite 
the fact that the dependency tracking described here is omitted from Vytiniotis et al. 
[99], the most detailed description of GHC’s solver, 75 the solver as implemented does 
indeed do dependency tracking and should support all of the innovations described in 
this chapter. 

Constraints in Bake are represented by unification telescopes, which are fists of 
possibly dependent unification variables, 76 with their types. Naturally, there are two 
sorts of unification variables: types a and coercions i. The solver finds concrete types 
to substitute in for unification variables a and concrete coercions to substitute in 
for unification variables i. Implication constraints [84, 99] are handled by classifying 
unification variables by quantified kinds and propositions. See Section 6.3. 

The algorithm is stated as several judgments of the following general form: 77 

E; 4/ b inputs outputs H D 

Most judgments are parameterized by a fixed signature E that defines the datatypes 
that are in scope. 78 The context 4/ is a generalization of contexts F; a context 4/ 
contains both PlCO variables and unification variables. Because this is an algorithmic 
treatment of type inference, the notation is careful to separate inputs from outputs. 
Everything to the left of is an input; everything to the right is an output. Most 
judgments also produce an output fl, which is a unification telescope, containing 
bindings for only unification variables. This takes the place of the emitted constraints 

75 In the paper describing OutsideIn [99], the authors separate out the constraint generation 
from the solver. They call the constraint-generation algorithm OutsideIn and the solver remains 
unnamed. I use the moniker OutsideIn to refer both to the constraint-generation algorithm and the 
solver. 

76 Depending on the source, various works in the literature refer to unification variables as existential 
variables (e.g., [24]) or metavariables (e.g., [37] and the GHC source code). I prefer unification 
variables here, as I do not wish to introduce confusion with existentials of data constructors nor the 
metavariables of my metatheory. 

77 The definitions for T and ft appear in Figure 6.2 on page 147. 

78 I do not consider in this dissertation how these signatures are formed. To my knowledge, there is 
no formal presentation of the type-checking of datatype declarations, and I consider formalizing this 
process and presenting an algorithm to be important future work. 
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seen in other constraint-generation algorithms. It also serves as a context in which to 
type-check the remainder of the syntax tree. 

The solver’s interface looks like this: 

E; $^, v ^A ; e 

That is, it takes as inputs the current environment and a unification telescope. It 
produces outputs of A, a telescope of variables to quantify over, and 0, the zonker 
(Section 6.3.1), which is an idempotent substitution from unification variables to 
other types/coercions. To understand the output A, consider checking the declaration 
y = Ax —>• x. The variable x gets assigned a unification variable type a. No constraints 
then get put on that type. When trying to solve the unification telescope o:i rre |Type, 
we have nothing to do. The way forward is, of course, to generalize. So we get 
A = o:| rre |Type and 0 = a/a. In the constraint-generation rules for declarations, the 
body of a declaration and its type are generalized over A. (See IDecl_Synthesize 
in Section 6.7.) 

Writing a type inference algorithm for a dependently typed language presents a 
challenge in that the type of an expression can be very intricate. Yet we still wish to 
infer types for unannotated expressions. To resolve this tension, Bake adheres to the 
following: 

Guiding Principle. In the absence of other information, infer a simple type. 
Guiding Principle. Never make a guess. 

For example, consider inferring a type for 
compose f g = Ax —>• f (g x) 

The function compose could naively be given either of the following types: 

compose :: (b -A c) -A (a -A b) -A (a -A c) 
compose :: V (a:: Type) 

{b :: a —> Type) 

(c::V(x::a)^f>xA Type) 

. II (f :: V (x :: a). II (y :: b x) -A c x y) 

(g :: n (x :: a) -A b x) 

(x:: a) 

-^cx(gx) 

However, we surely want inference to produce the first one. If inference did not tend 
toward simple types, there would be no hope of retaining principal types in the 
system. I do not prove that Bake infers principal types, as doing so is meaningless 
without some non-deterministic specification of the type system, which is beyond the 
scope of this work. However, I wish to design Dependent Haskell with an eye toward 
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establishing a principal types result in the future. Inferring only rank-1 types still 
allows for higher-rank types in a bidirectional type system [74], Accordingly, it is 
my hope that inferring only simple types will allow for Dependent Haskell to retain 
principal types. 

The second guiding principle is that Bake should never make guesses. Guesses, 
after all, are sometimes wrong. By “guess” here, I mean that the algorithm and solver 
should never set the value of a unification variable unless doing so is the only possible 
way an expression can be well typed. Up until this point, GHC’s type inference 
algorithm has resolutely refused to guess. This decision manifests itself, among other 
places, in GHC’s inability to work with a function f :: F a —>■ F a, where F is a type 
function. 79 The problem is that, from f 3, there is no way to figure out what a should 
be, and GHC will not guess the answer. 

A key consequence of not making any guesses is that Bake (more accurately, the 
solver it calls) does no higher-order unification. Consider this example: 

fun :: a —>• (f $ a) 

— NB: The use of $ means that f is not a matchable function 
bad :: Bool —>■ Bool 
bad x = fun x 

In the body of bad , it is fairly clear that we should unify f with the identity function. 
Yet the solver flatly refuses, because doing so amounts to a guess, given that there are 
many ways to write the identity function. 80 

In my choice to avoid higher-order unification, my design diverges from the designs 
of other dependently typed languages, where higher-order unification is common. Time 
will tell whether the predictability gotten from avoiding guesses is worth the potential 
annoyance of lacking higher-order unification. Avoiding guesses is also critical for 
principal types. See Vytiniotis et al. [99, Section 3.6.2] for some discussion. 

Now that we’ve seen the overview, let’s get down to details. 

6.2 Haskell grammar 

I must formalize a slice of Dependent Haskell in order to describe an elaboration 
procedure over it. The subset of Haskell I will consider is presented in Figure 6.1 on 
the next page. Note that all Haskell constructs are typeset in upright Latin letters; 
this is to distinguish these from PlCO constructs, typeset in italics and often using 
Greek letters. 

The version of Dependent Haskell presented here differs in a few details from the 
language presented in Chapter 4. These differences are to enable an easier specification 

79 Unless F is known to be injective [86]. 

80 Note that my development does not natively support functional extensionality, so that these 
different ways of writing an identity function are not equal to one another. 
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declaration 

program 


Figure 6.1: Formalized subset of Dependent Haskell 


of the elaboration algorithm. Translating between the “real” Dependent Haskell of 
Chapter 4 and this version can be done by a preprocessing step. Critically, (but with 
one exception) no part of this preprocessor needs type information. For example, 
V a b. ... is translated to V@a.V@6.... so that it is easier to consider individual bound 
variables. 

The exception to the irrelevance of type information is in dealing with pattern 
matches. Haskell pattern matches can be nested, support guards, perhaps view patterns, 
perhaps pattern synonyms [76], etc. However, translating such a rich pattern syntax 
into a simple one is a well studied problem with widely used solutions [2, 101] and 
I thus consider the algorithm as part of the preprocessor and do not consider this 
further. 


6.2.1 Dependent Haskell modalities 

Let’s now review some of the more unusual annotations in Dependent Haskell, originally 
presented in Chapter 4. Each labeled paragraph below describes an orthogonal feature 
(visibility, matchability, relevance). 

The @ prefix Dependent Haskell uses an @ prefix to denote an argument that 
would normally be invisible. It is used in two places in the grammar: 

• An @-sign before an argument indicates that the argument is allowed to be 
omitted, yet the user has written it explicitly. This follows the treatment in my 
prior work on invisible arguments [33]. 

• An @-sign before a quantified variable (in the definition for qvar) indicates that 
the actual argument may be omitted when calling a function. In a A-expression, 
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this would indicate a pattern that matches against an invisible argument (Section 
4.2.3.1). In a II- or V-expression, the @-sign is produced by the preprocessor 
when it encounters a V ... . or II... . quantification. 

Ticked quantifiers Three of the quantifiers that can be written in Dependent 
Haskell come in two varieties: ticked and unticked. A ticked quantifier introduces 
matchable (that is, generative and injective) functions, whereas the unticked quantifier 
describes an unrestricted function space. Recall that type constructors and data 
constructors are typed by matchable functions, whereas ordinary A-expressions are 
not. 

Relevance The difference between V and n in Dependent Haskell is that the former 
defines an irrelevant abstraction (fully erased during compilation) while the latter de¬ 
scribes a relevant abstraction (retained at runtime). In terms, an expression introduced 
by A is a relevant abstraction; one introduced by A is an irrelevant one. 

6.2.2 let should not be generalized 

Though the formalized Haskell grammar includes let, I will take the advice of Vytiniotis 
et al. [98] that let should not be generalized. As discussed at some length in the work 
cited, local, generalized lets are somewhat rare and can easily be generalized by a type 
signature. For all the same reasons articulated in that work, generalizing let poses a 
problem for Bake. We thus live with an ungeneralized let construct. 

6.2.3 Omissions from the Haskell grammar 

There are two notable omissions from the grammar in Figure 6.1 on the preceding 
page. 

Type constants The Haskell grammar contains no production for H , a type con¬ 
stant. This is chiefly because type constants must be saturated with respect to 
universals in PlCO, whereas we do not need this restriction in Haskell. Accordingly, 
type constants are considered variables that expand to type constants that have been 
^-expanded to take their universal arguments in a curried fashion. For example, Just 
in Haskell, which can appear fully unsaturated, becomes Aa:i rre |Type. Justly in PlCO. 

Recursive let Following the decision not to include a letrec construct in PlCO 
(Section 5.1.2), the construct is omitted from the formalized subset of Haskell as 
well. Having a formal treatment of letrec would require a formalization of Haskell’s 
consideration of polymorphic recursion [41, 62, 67], whereby definitions with type 
signatures can participate in polymorphic recursion while other definitions cannot. 
In turn, this would require a construct where a polymorphic function is treated 
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Metavariables: 
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Grammar extensions: 
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a | l 

0 | 0, Vz.r/a | 0, Vz.q/t 

a : p V A.k | i : V A.cj) 

0 1 n,u 

0|vM 


type/kind 

coercion 

unification variable 
zonker (Section 6.3.1) 
generalizer (Section 6.5) 
unit. var. binding 
unification telescope 
typing context 


I elide the V when the list of variables or telescope quantified over would be empty. 
Figure 6.2: Additions to the grammar to support Bake. 


monomorphically in a certain scope and polymorphically beyond that scope. 81 The 
problems faced here are not unique to (nor made particularly worse by) dependent 
types. I thus have chosen to exclude this construct for simplicity. 

We have now reviewed the source language of Bake, and the previous chapter 
described its target language, PlCO. I’ll now fill in the gap by introducing the additions 
to the grammar needed to describe the inference algorithm. 


6.3 Unification variables 

The extensions to the grammar to support inference are in Figure 6.2. These extensions 
all revolve around supporting unification variables, which are rather involved. One 
might think that unification variables need not be so different from ordinary variables; 
constraint generation could produce a telescope of these unification variables and 
solving simply produces a substitution. However, this naive view does not work out 
because of unification variable generalization. 82 

Consider a A-abstraction over the variable x. When doing constraint generation 
inside of the A, the kinds of fresh unification variables might mention x. Here is a case 
in point, which will serve as a running example: 

81 Readers familiar with the internals of GHC may recognize its AbsBinds data constructor in this 
description. Formalizing all of its intricacies would indeed be required to infer the type of a letrec. 

82 The treatment of unification variables throughout Bake is essentially identical to the treatment 
by Gundry [37], which is itself closely based on the work of Dunfield and Krishnaswami [24]. 
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poly :: V_/' (b::j) ->■ ... 
example = Xk a —>• poly k a 

Type inference can easily discover that the kind of a is k. But in order for the inference 
algorithm to do this, it must be aware that k is in scope before a is. Note that when 
we call the solver (after type-checking the entire body of example ), k is not in scope. 
Thus, as we produce the unification telescope during constraint generation over the 
body of example, we must somehow note that the unification variable a (the type of 
a) can mention k. 

This means that unification variable bindings are quantified over a telescope A. 
(You can see this in the definition for u in Figure 6.2 on the preceding page.) In the 
vocabulary of OutsideIn, the bindings in A are the givens under which a unification 
variable should be solved for and a unification variable binding a : p V A.k or l : V A.0 
with a non-empty A is an implication constraint. 


6.3.1 Zonking 

Solving produces a substitution from unification variables to types/coercions. Fol¬ 
lowing the nomenclature within GHC, I call applying this substitution zonking. The 
substitution itself, written 0, is called a zonker. 

Zonkers pose a naming problem. Consider solving to produce the zonker for example , 
above. Suppose the type of a is assigned to be a. We would like to zonk a to k. However, 
as before, k is out of scope when solving for a. We thus cannot just write k/a, as that 
would violate the Barendregt convention, where we can never name a variable that is 
out of scope (as it might arbitrarily change due to a-renaming). 

The solution to this problem is to have all occurrences of unification variables 
applied to vectors A 83 When we zonk a unification variable occurrence a&, the vector 
-0 is substituted for the variables in the telescope A that a’s kind is quantified over. 

Here is the formal definition of zonking: 


Definition (Zonking [Definition E.19]). A zonker can be used as a postfix function. 
It operates homomorphically on all recursive forms and as the identity operation on 
leaves other than unification variables. Zonking unification variables is defined by these 
equations: 


V z.t/o: e © 
otherwise 
Vz.j/l e © 
otherwise 


Q^[ 0 ] = r [^[ 0 ]/^] 

a^[0\ = % 0] 

bqe] = 7f0[ 0 ]/^] 
= %->] 


Continuing the example from above, we would say that a has the type a^, where 
we have a :i rre i V /c:| rre |Type.Type. The solver will create a zonker with the mapping 

83 Recall that 0 is a metavariable that can stand for either a type or a coercion. Thus 0 is a mixed 
list of types and coercions, suitable for substituting in for a list of type/coercion variables z. 
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Figure 6.3: Extra rules in PlCO judgments to support unification variables 

V j.j/a (where I have changed the variable name for demonstration). This will zonk 
ak to become j[k/j] which is, of course k as desired. 

Note that the quantification we see here is very different from normal 11-quantifica¬ 
tion in PlCO. These quantifications are fully second class and may be viewed almost 
as suspended substitutions. 

6.3.2 Additions to PlCO judgments 

The validity and typing judgments in PlCO all work over signatures E and contexts T. 
In Bake, however, we need to be able to express these judgments in an environment 
where unification variables are in scope. I thus introduce mixed contexts \t, containing 
both PlCO variables and unification variables. 

Accordingly, I must redefine all of the PlCO judgments to support unification 
variables in the context. These judgments are written with a N turnstile in place of 
Pico’s h turnstile. There are also several new rules that must be added to support 
unification variables. These rules appear in Figure 6.3. 

Note the rules Ty_UVar and Co_UVar that support unification variable 
occurrences. The unification variables are applied to vectors 0 which must match the 
telescope A in the classifier for the unification variable. In addition, this vector is 
substituted directly into the unification variable’s kind. 

These definitions support all of the properties proved about the original PlCO 
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judgments, such as substitution and regularity. The statements and proofs are in 
Appendix E. 

6.3.3 Untouchable unification variables 

Vytiniotis et al. [99, Section 5.2] introduces the notion of touchable unification variables, 
as distinct from untouchable variables. Their observation is that it is harmful to assign a 
value to a “global” unification variable when an equality constraint is in scope. “Global” 
here means that the unification variable has a larger scope than the equality constraint. 
We call the “local” unification variables touchable, and the “global” ones untouchable. 
OutsideIn must manually keep track of touchability; the set of touchable unification 
variables is an extra input to its solving judgment. 

In Bake, on the other hand, tracking touchability is very easy with its use of unifi¬ 
cation telescopes: all unification variables quantified by the same equality constraints 
as the constraint under consideration are touchable; the rest are untouchable. 

To make this all concrete, let’s look at a concrete example (taken from Vytiniotis 
et al. [99]) where the notion of touchable variables is beneficial. 

Suppose we have this definition: 

data T a where 

K :: (Bool ~ a) *#• Maybe Int -A T a 

I have written this GADT with an explicit equality constraint in order to make the 
use of this constraint clearer. The definition for K is entirely equivalent to saying 
K :: Maybe Int -A T Bool. 

We now wish to infer the type of 

Ax -a- case x of { K n —> isNothing n} 

where isNothing :: V a. Maybe a -A Bool checks for an empty Maybe. Consider any 
mention of a new unification variable to be fresh. We assign x to have type cto and the 
result of the function to have type /3 0 - By the existence of the constructor K in the 
case-match, we learn that Oq should really be T a i. Inside the case alternative, we 
now have a given constraint Bool ~ oq. We then instantiate the polymorphic isNothing 
with a unification variable /A, so that the type of isNothing is Maybe d\ -A Bool. We 
can now emit two equality constraints: 

• The argument type to isNothing , Maybe d\ , must match the type of n, Maybe Int. 

• The return type of the case expression (/3 0 ) is the return type of isNothing 
(Bool). 
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Pulling this all together, we get the following unification telescope: 

= [ « 0 ; lrre|Type, 

/3 0 :irreiType, 

aiVei Type, 

Lo'-ao ~ 7O'!, 

liTrei V(c:6oo/ ~ op).Type, 

ti : V(c:6oo/ ~ ai).(Maybe/3i c ~ Maybe Int), 

l 2 : V(c:6oo/ ~ op).(A) ~ Bool ) 

Before we walk through what the solver does with such a telescope, what should 
it do? That is, what’s the type of our original expression? It turns out that this is 
not an easy question to answer! The expression has no principal type. Both of the 
following are true: 

(Ax — y case x of {K n —>• isNothing n}) :: V a. 7 a —>• a 
(Ax —>■ case x of { K n —> isNothing n }) :: V a. T a —>• Bool 

Note that neither T a —> a nor T a Bool is more general than the other. 

We would thus like the solver to fail when presented with this unification telescope. 
This is true, even though there is a solution to the inference problem (that is, a valid 
zonker 0 with a telescope of quantified variables A; see the specification of b&| v , Section 
6 . 1 ): 


A = a:, rre |Type 

0=7 a/oo) 

Bool/80, 
a/a 1 , 

(7a)Ao, 

V c.lnt//3i, 

V c.(Maybe \nt)/i \, 

V c.(Bool) / <-2 

The problem is that here is another valid substitution for /3 0 and l 2 : 

0 = ..., 

a/A), 

V c.sym c/i 2 

These zonkers correspond to the overall type T a —> Bool and T a —>• a, respectively. 

We must thus ensure that the solver rejects outright. This is achieved by 
making /3 0 untouchable when considering solving the i 2 constraint. 84 As described 
84 Why this particular mechanism works is discussed in some depth by Vytiniotis et al. [99, Section 
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by Vytiniotis et al. [99, Section 5.5], the solver considers the constraints individually. 
When simplifying (OutsideIn’s terminology for solving a simple, non-implication 
constraint) the i\ and constraints, any unification variable not quantified by c is 
considered untouchable. 85 Thus, f3 0 is untouchable when simplifying t 2 , so the solver 
will never set f3 0 to anything at all. It will remain an ambiguous variable and a type 
error will be issued. 

Contrast this with aq, which is also not set by the solver. This variable, however, 
is fully unconstrained and can be quantified over and turned into the non-unification 
variable a. There is no way to quantify over /3 0 , however. 

Despite not setting /3 0 , the solver is free to set /3i which is considered touchable, 
as it is also quantified by c. The unification variable /3\ is fully local to the case 
alternative body, and setting it can have no effect outside of the case expression. In 
the terminology of OutsideIn, that unification would be introduced by 3/3i in an 
implication constraint. In our example, the ability to set (3 1 means that we get only 
one type error reported, not two. 

6.4 Bidirectional type-checking 

Like previous algorithms for GHC/Haskell [33, 37, 74], Bake takes a bidirectional 
approach [78]. The fundamental idea to bidirectional type-checking is that, sometimes, 
the type inference algorithm knows what type to look for. When this happens, the 
algorithm should take advantage of this knowledge. 

Bidirectional type-checking works by defining two mutually recursive algorithms: a 
type synthesis algorithm and a type checking algorithm. The former is used when we 
have no information about the type of an expression, and the latter is used when we 
do indeed know an expression’s expected type. The algorithms are mutually recursive 
because of function applications: knowing the result type of a function call does not 
tell you about the type of the function (meaning the checking algorithm must use 
synthesis on the function), but once we know the function’s type, we know the type of 
its arguments (allowing the synthesis algorithm to use the more informative checking 
algorithm). 

Historically, bidirectional type-checking in Haskell has been most useful when 
considering higher-rank polymorphism—for example, in a type like (V a. a —>• a) — >• Int. 
Motivating higher-rank types would bring us too far afield, but the literature has 
helpful examples [33, 74] and there is a brief introduction in Section 2.5. Naturally, 
Dependent Haskell continues to use bidirectional type-checking to allow for higher-rank 
types, but there is now even more motivation for bidirectionality. 

5.2], 

85 To make this a bit more formal, I would need to label the quantification by c by some label 
drawn from an enumerable set of labels. The touchable unification variables would be those quantified 
by the same label as the constraint being simplified. We cannot just use the name c, as names are 
fickle due to potential a-variation. 
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As discussed above (Section 6.3.3), bringing equality constraints into scope makes 
some unification variables untouchable. In practice, this means that the result type of 
a GADT pattern match must be known; programmers must put type annotations on 
functions that perform a GADT pattern match. 

In a dependently typed language, however, any pattern match might bring equality 
constraints into scope, where the equality relates the scrutinee with the pattern. For 
example, if I say something as simple as case b of { True -4 x; False -4 y }, I may want 
to use the fact that b ~ True when type-checking x or 6 ~ False when type-checking 
y. This is, of course, dependent pattern matching (Section 4.3.3). Our problem now is 
that it seems that every pattern match introduces an equality constraint, meaning 
that the basic type inference of Haskell might no longer work, stymied by untouchable 
variables. 

The solution is to take advantage of the equality available by dependent pattern 
matching only when the result type of the case expression is being propagated 
downwards—that is, when the inference algorithm is in checking mode. If we do 
not know a case expression’s overall type, then the pattern match is treated as a 
traditional, non-dependent pattern match. Without bidirectional type-checking, the 
user might have to annotate which kind of match is intended. 86 

6.4.1 Invisibility 

As discussed in Section 4.2.3, Dependent Haskell programmers can choose the visibility 
of their arguments: A visible argument must be provided at every function call, while 
an invisible one may be elided. If the programmer wants to write an explicit value to 
use for an invisible argument, prefixing the argument with @ allows it to stand for the 
invisible parameter. 

In the context of type inference, though, we must be careful. As explored in my 
prior work [33], invisible arguments are sometimes introduced at the whim of the 
compiler. For example, consider 

— isShorterThan :: [a] -4 [b] -4 Bool 
isShorterThan xs ys = length xs < length ys 

Note that the type signature is commented out. The function isShorterThan takes two 
invisible arguments, a, and b. Which order should they appear in? Without the type 
signature for guidance, it is, in general, impossible to predict what order these will be 
generalized. See Eisenberg et al. [33, Section 3.1] for more discussion on this point. 

Despite the existence of functions like isShorterThan with fully inferred type signa¬ 
tures, we wish to retain principal types in our type system—at least in the subset of 
the language that does not work with equality constraints. We thus must have three 
different levels of visibility: 

86 The Dependent Haskell described by Gundry [37] indeed has the user annotate this choice for 
case expressions. Due to Gundry’s restrictions on the availability of terms in types (see his Section 
6.2.3), however, the bidirectional approach would have been inappropriate in his design. 
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Required parameters (also called visible) must be provided at function call sites. 


Specified parameters are invisible, but their order is user-controlled. These parame¬ 
ters are to functions with type signatures or with an explicit V.... 

Inferred parameters (called “generalized” in Eisenberg et al. [33]) are ones invented by 
the type inference algorithm (like the parameter a in the example used to explain 
untouchable variables; see Section 6.3.3). They cannot ever be instantiated 
explicitly. All coercion abstractions are inferred. 

Note that these three levels of visibility are not a consequence of dependent types, 
but of having an invisibility override mechanism; these three levels of visibility are 
fully present in GHC 8. In the judgments that form Bake, I often write a subscript 
Req, Spec, or Inf to II symbols indicating the visibility of the binders quantified over. 
These subscripts have no effect on well-formedness of types and are completely absent 
from pure PlCO. 

Following my prior work, both the synthesis and checking algorithms are split into 
two judgments apiece: one written 1^ and one written |A. The distinction is that the 
latter works with types that may have invisible binders, while the former does not. For 
example, a type produced by the judgment in synthesis mode is guaranteed not to 
have any invisible (that is, specified or inferred) binders at the outermost level. Thus 
when synthesizing the type of ti in the expression ti t 2 , we use the kj judgment, as 
we want any invisible arguments to be inferred before applying ti to t 2 . Considering 
the algorithm in checking mode, when processing a traditional A-expression, we want 
the rule to be part of the \$ judgment, to be sure that the algorithm has already 
skolemized (Section 6.4.3) the known type down to one that accepts a visible argument. 
Conversely, the rule for an expression like A @a —>• ... must belong in the judgment, 
as we want to see the invisible binders in the type to match against the invisible 
argument the programmer wishes to bind. 

The interplay between the starred judgments and the unstarred nudges this system 
toward principal types. Having these two different judgments is indeed one of the main 
innovations in my prior work [33], where the separation is necessary to have principal 
types. 

6.4.2 Subsumption 

Certain expression forms do not allow inward propagation of a type. As mentioned 
above, if we are checking an expression f x against a type r, we have no way of usefully 
propagating information about t into f or x. Instead, we use the synthesis judgment 
for f and then check x’s type against the argument type found for f. After all of this, 
we will get a type r' for f x. We then must check r' against r—but they do not have 
to match exactly. For example, if r' is V a. a — > a and r is Int -A Int, then we’re fine, 
as any expression of the former type can be used at the latter. 
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Figure 6.4: Subsumption in Bake (simplified) 


What we need here is a notion of subsumption , whereby we say that V a. a A a 
subsumes Int —>• Int, written 


V a. a —>• a < Int -A Int 

For reasons well articulated in prior work [74, Section 4.6], my choice for the subsump¬ 
tion relation does deep skolemization. This means that the types V a. Int —>• a —>• a and 
Int —>• V a. a —>• a are fully equivalent. This choice is furthermore backward compatible 
with the current treatment of non-prenex types in GHC. 

Bake’s subsumption relation is in Figure 6.4. The rules in this figure are simplified 
from the full rules (which appear in Section D.9), omitting constraint generation and 
elaboration. The rules in each judgment are meant to be understood as an algorithm, 
trying earlier rules before later ones. Thus, for example, rule Sub_Unify is not as 
universal as it appears. 

The entry point is the bottom, unstarred subsumption judgment. It computes 
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the prenex form of k 2 using the auxiliary judgment f^ re and instantiates K\. (The 
Spec superscript to fe st says to instantiate any argument that is no more visible than 
Spec —that is, either Inf or Spec arguments.) The instantiated and prenexed k' 2 are 
then compared using the starred subsumption judgment. 87 

The starred judgment has the usual contravariance rule for functions. This rule, 
however, has three interesting characteristics. 

Dependency We cannot simply compare k 2 < tt 4 . The problem is that k 2 has a 
variable a of type K\ in scope, whereas « 4 has a variable b of type tc 3 in scope. Contrast 
this rule to a rule for non-dependent functions where no such bother arises. In the 
fully detailed versions of these judgments, learning that K\ < n 2 gives us a term r 
such that t : n_: Re |K 1 . k 2 — that is, a way of converting a k,\ into a k 2 . I include such 
a t when checking whether < K\. This r is then used to convert b : k 3 into a value 
of type Ki, suitable for substitution in for a. With this substitution completed, we 
can perform the subsumption comparison against tc 4 as desired. 

Matchable functions subsume unmatchable ones Rule Sub_Fun includes a 
subsumptive relationship among the two flavors of II. Whenever an unmatchable 
II-type is expected, surely a matchable ’II-type will do. Thus we allow either II on the 
left of the <. Note that the other way would be wrong: not only might an unmatchable 
II-type not work where a matchable ’II-type is expected, but we also have no way of 
creating the ’II-type during elaboration. Our need to elaborate correctly keeps us from 
getting this wrong. 

Irrel subsumes Rel Finally, the rule also includes a subsumptive relationship among 
relevances. If the relevances pi and p 2 match up, then all is well. But also if p\ is Irrel 
and p 2 is Rel, we are OK. If p 2 is Rel, that says that the expression we are checking is 
allowed to use its argument relevantly, but nothing goes wrong if the expression, in 
fact, does not (that is, if p\ is Irrel). Once again, elaboration keeps us honest here; if 
the rule is written the wrong way around, there is no sound way to elaborate. 

6.4.3 Skolemization 

In checking mode, the 1^ judgment skolemizes any invisible quantifiers in the known 
type. 88 As an example, consider 

(Ax 4x)::Va.a4a 

87 The stars on these judgments have a different meaning than the star on bjj; they are borrowed 
from the notation by Peyton Jones et al. [74], not Eisenberg et al. [33]. 

88 I am following Peyton Jones et al. [74] in my use of the word “skolem”. I understand that this word 
may have slightly different connotation in a logical context, but my use here has become standard in 
the study of GHC/Haskell. 
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When checking the A-expression against that type, we first must dispose of the V a. 
This is done by essentially making a a fresh type constant, equal to no other. This act 
is called skolemization; a becomes a skolem. The variable x is then given this type a, 
and the body of the A indeed has type a as desired. 

As we look at more complicated examples, a question arises about how deeply to 
skolemize. Here is an illustrative example, taken from prior work [34]: 

x = A5 z -4 z 

— x is inferred to have type V a. Int -4 a -4 a 
y :: Int —> V b. b -4 b 
y = x 

In this example, we are checking x of type V a. Int -4 a -4 a against the type 
Int —> V b. b —> b. We must be a bit careful here, though: x’s type is fully inferred, and 
thus its quantification over a is Inf, not Spec. With the right flags, 89 GHC prints x’s 
type as V {a}. /nt —>■ a —>■ a to denote that it is not available for a visibility override. 

The type we are checking against does not have any invisible binders at the top 
(its first binder is the visible one for Int), so we do not initially skolemize. We instead 
discover that there is no checking rule for variables and have to use the fall-through 
case for checking, which does synthesis and then a subsumption check. However, a 
naive approach would be wrong here: if we synthesize the type of x, we will get 
the instantiated Int -4 a -4 a. This is because Inf binders are always instantiated 
immediately, much like in the original syntax-directed version of the Hindley-Milner 
type system [18, 20]. In the subsumption check, we will want to set a to be b, the 
skolem created from y’s type signature. We will be unable to do so, however, because 
doing so would be ill scoped: a occurs in the unification telescope before b is ever 
brought into scope. This means that it would be ill scoped for the value chosen for 
a to refer to b. 90 It would quite unfortunate to reject this example, because the 
subsumption judgment, with its deep skolemization, would have this work out if only 
we didn’t instantiate that Inf binder so eagerly. 

Instead, I have written the ITyC_Infer rule (details in Section 6.6.2) to eagerly 
skolemize the known type deeply, effectively before ever looking at the expression. 
This puts b firmly into scope when consider a, and the subsumption check (and later 
solver) succeeds. 

The solution to this problem proposed in prior work is to do deep skolemization 
in the checking 1^ judgment. This works in the System SB of Eisenberg et al. [33]. 
However, it fails us here. The problem is that Dependent Haskell allows for constructs 
like An @a -4 .... If we check that expression against Int -4 V a. a -4 a, we want 

89 - f print - explicit - f or alls, specifically 

"Saying that this example fails because of scoping is a vast improvement over the state of affairs 
in Eisenberg et al. [34], where a delicate line of reasoning based on the subtleties of the Barendregt 
convention is necessary to show how this example goes awry. By tracking our unification variables in 
a telescope, problems like this become much clearer. 


157 



the as to match up. Yet deeply skolemizing the type we are checking against will 
eliminate the a and our algorithm will reject the code. We thus instead do shallow 
skolemization in and instead save the deep skolemization until we are forced to 
switch into synthesis mode. 

Returning to the x/y example, here is how it plays out: 

1. The variable x is inferred to have type V{a}. Int a ^ a when processing the 
declaration for x. 

2 . We then check the body of y against the type Int -A V b. b —>• b. As there are 
no invisible binders, no skolemization happens right away. 

3. We quickly find that no checking rules apply. We then deeply skolemize the 
expected type, getting Int —>• b —>• b for a skolem b. 

4. Now, we synthesize the type for the expression x, getting Int —>• a —>• a. 

5. The subsumption relation checks whether Int —>• a —>• a subsumes Int —tb—t b. 
This is indeed true with a := b, and the definition for y is accepted. 91 

We have thus accepted our problem example and remain in line with the declarative 
system proposed in my prior work [33, Section 6.2], 


6.5 Generalization 

There is one final aspect of the inference algorithm that requires study before we 
look at the individual pieces: the generalization operation. 92 That said, in terms of 
understanding the Bake algorithm, having a strong grasp on generalization is not 
terribly important; this is merely a technical step needed to make the mathematics 
hold together. 

Suppose we are synthesizing the type of a A-expression Ax —>• r. We choose a 
unification variable a for the type of x. We then must put x: Re | 0 : into the context when 
synthesizing the type for r. Synthesizing this type will produce a unification telescope 
0. Now we have a problem: what unification telescope will we return from synthesizing 
the type of the entire A-expression? It looks something like ceVeiType, x: Re |«, Q but, 
critically, that is not a unification telescope, as that context contains a binding for an 
ordinary PlCO variable, x. 

91 Although not visible in the simplified presentation of Sub_DeepSkol in Figure 6.4 on page 155, 
it is critical that k -2 is skolemized before m is instantiated, lest we end up with the same scoping 
problem. This can be seen in the full rule (Section D.9) with the fact that we include fii in the final 
generalization step. In contrast to other potential pitfalls mentioned earlier, leaving fli out of this 
line does not imperil the soundness of elaboration; it is only a matter of expressiveness of the source 
Haskell. 

92 What I call generalization here is precisely what Gundry [37, Section 7.5] calls “parameterisation” 
and writes with /b 
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A fl';£| Generalize Q over A. 


£o = cn-y dom(A) 


y A -w 0;0 

^[£o] ^ A ^ 


• fi';£ 


p VA'./t,fi - 


♦ a: p VA,A , ./c,fi , ;4br^ 


IGen_TyVar 


£o = i dom(A) fl[£ 0 ] A -w fl'; £ 
t : VA'.^fi^ A t : V A, A'.(/>, IT; £ 0 , £ 


IGen_CoVar 


Figure 6.5: Bake’s generalization operation 

It might be tempting at this point simply to return a mixed telescope of unification 
variables and PlCO variables, and just to carry on. The problem here is that we will 
lose track of the local scope of x. Perhaps something later, outside of the A-expression, 
will end up unifying with x—which would be a disaster. No, we must get rid of it. 

The solution is to generalize Q over x. This operation is written Q <—> x:R e |Type 
O'; £. (The mnemonic behind the choice of ^ is that we are essentially moving the 
x: Re |Type binding to the right, past O.) The output unification telescope O' binds 
the same unification variables as 0, but each one will be generalized with respect to x. 
The definition of this judgment appears in Figure 6.5. The rules are a bit complicated 
by the fact that we may generalize a unification variable binding multiple times; both 
recursive rules thus assume a telescope A' that has already been generalized. 

The new construct £ is a generalizer. It is a substitution-like construct that maps 
unification variables to vectors, which you may recall are lists of arguments ip. In 
this case, we simply use the domain of A as the vector, where my use of dom(A) 
as a list of arguments means to insert the irrelevance braces around irrelevantly 
bound variables. Generalizers are necessary because generalizing changes the type of 
unification variables; we must then change the occurrences of them as well. 

Generalizers operate like this: 

Definition (Generalizing [Definition E.31]). A generalizer is applied postfix as a 
function. It operates homomorphically on all recursive forms and as the identity 
operation on leaves other than unification variables. Generalizing unification variables 
is defined by these equations: 


ip i e £ =# 

%J£] = 


otherwise 

= 

a m 

L (->• -0i G £ => 

= 


otherwise 

L = 

L m 


Just like the generalization judgment (Figure 6.5), the generalization operation [£] 
prepends the newly generalized variables to those already there. 
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E;f 

E; \k s i—IQ 

E; T; p t : 

E; 'I'; re 0 ; r 0 alt : k alt H O 

E; 4/; n 0 ', t 0 like alt : k alt H O 

E; 4/ l^qvar a : /c; v H fl 
E; 4/ aqvar a : re H fl 
E; 4/ b |, aqvar : k a : «/; x.t H fl 
quant II; p 

hpgn k: pi 7; II; a; p 2 ; «i; fc 2 Hfi 
E; 1/ b£ rut alt; h 7 ; A; H; r H O 
^mst "07 “I ^ 

E; T l^ ec | decl x : k : = r 
El; T l^ rog prog T; 9 


synthesize a type (no invis. binders) 
synthesize a type 
check a type (no invis. binders) 
check a type 

check a polytype (always with kind Type) 

check an argument at relevance p 

check a case alt. against an unknown type 

check a case alt. against a known type 

synth. type of a bound var. 

synth. type of a bound var. (w/o vis. marker) 

check type of a bound var. (w/o vis. marker) 

interpret a quantifier 

extract components of a function type 

extract components of a scrutinee type 

instantiate a type 

check a declaration 

check a program 


Figure 6.6: Bake judgments 

6.6 Type inference algorithm 

The schema of the judgments that define Bake appear in Figure 6.6. I will not walk 
through each rule of each judgment to explain its inner workings. As discussed in 
the introduction to this chapter, the individual rules are largely predictable. They 
can be reviewed in their entirety in Appendix D, and the statements of lemmas that 
assert the soundness of many of these judgments appear in Section 6.8.1.4. Instead 
of a thorough review of the algorithm, this section will call out individual rules with 
interesting characteristics. 

6.6.1 Function application 

As discussed above (Section 6.4) function applications can only synthesize their type. 
The two rules for synthesizing the type of a function application (one for regular 
application and one for application with @) appear in Figure 6.7 on the next page, 
along with auxiliary judgments. 

Walking through the ITy_App rule, we see that Bake first infers the type k 0 
for the Haskell expression ti, elaborating ti to become and producing a unification 
telescope fThe type for Ti, though, might not manifestly be a function. This would 
happen, for example, when inferring the type of Ax y —>• x y, where the type initially 
assigned to x is just a unification variable a. Instead of writing kq as a function, Bake 
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ITy_App 


E; ^ ti Ti : Kq H H x 
ten Ko ; Rel 7; II; a; p; Kp, k 2 H H 2 

E; 'I', Hi, H 2 ; p f^ rg t 2 : Ki -w if 2 - r 2 H H 3 
E; 'k l| tx t 2 (n > 7) ^2 : ^ 2 [T 2 /a] H Hi, H 2 , H 3 


E; 'll ti n : n S pe C a:pKi- R 2 H Hi 
E; 'I', Hi; p f^ rg t 2 : «i ^ 2 ; t 2 H H 2 
E;\l/ (A ti @t 2 Ti -02 : ^[^/a] H Hi,H 2 


ITy_AppSpec 


ten k; Pi ^ 7 ; n; a; p 2 ; Ri; r 2 H H Extract out the parts of a function kind. 


ten n Req a: p /ci. n 2 ; Po (n Req a: p /ci. /c 2 ); II; a; p; #c x ; k 2 H0 

fresh l fresh/ 3 i,/ 3 2 

H = )9i:i rre |Type,^ 2 :| rre |Type,t:/Co ~ n Req o: p ^i.^ 2 
ten Ro; a; p; /?i; P 2 H H 


: k- 


■ ip] t H H | Check a function argument against its known type. 
E; Ite t : k t H H 


E; \l/; Rel l^ rg t : s^rjrHf 
E; Rel(^) |t:^rHH 


E; ; Irrel t : 


> {t}; r H H 


IArg Irrel 


Figure 6.7: Function applications in Bake 

instead uses its ten judgment, which extracts out the component parts of a function 
type. 

It may be helpful in understanding the ten judgment to see its correctness property, 
as proved in Section E.9: 

Lemma (Function position [Lemma E.37]). If E; \I/ tf y k : Type and ten r; Pi 
7; II; a; p 2 ; up, k 2 H H, then E; \l/, H 7 : k ~ n Req a: P2 Ri. k 2 . 

We can see here that ten produces a coercion 7 that relates the input type k to 
the output type Iia\ P2 K\. k 2 . The input relevance pi is to be used as a default—B ake 
will assume that a function uses its argument relevantly unless told otherwise. Note 
that relevance of arguments is not denoted in the user-written source code. 

Looking at the definition of ten, we see two cases: 

• If the input type k is manifestly a II-type, Bake just returns its component 
pieces along with a reflexive coercion. 
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• Otherwise, it invents fresh unification variables as emits a constraint relating 
this variables to the input. 

It might be tempting to define [75 n only by the second rule, IFun_Cast, but this 
would greatly weaken Bake’s power. Doing so would mean that the bidirectional 
algorithm would never be able to take advantage of knowing a function’s argument 
type. Furthermore, note that /3 2 , the result type of the function in IFun_Cast, is not 
generalized with respect to ; a function type inferred via IFun_Cast will surely 
be non-dependent. This decision was made in keeping with the guiding principle that 
only simple types should be inferred. 

Once we have extracted the component parts of the function type, we can check the 
argument with the fy rg judgment. This judgment takes the relevance of the argument 
as an input; it simply uses the checking judgment and insert braces as appropriate. 

Contrast the behavior of ITy_App to that of ITy_AppSpec, which, crucially, 
does not use ( 73 n . Consider what would happen if the function’s type is not manifestly 
a Il-type. We could, like in IFun_Cast invent unification variables and emit a 
constraint. But this would mean that the argument is inferred , not specified. Using an 
inferred argument with a visibility override violates the inference principles set forth 
by Eisenberg et al. [33] and would surely eliminate the possibility of principal types. 
Accordingly, ITy_AppSpec avoids such behavior and simply looks to make sure that 
the function’s type is of the appropriate shape. If it is not, Bake issues an error. 


6.6.2 Mediating between checking and synthesis 

The two modes of Bake meet head-on when we are checking an expression (such as a 
function application) that has no rules in the checking judgment. The fall-through 
case of the checking judgment is this rule: 


fpte ^2 A; K 2 ] T2 

O 1 — y A Of] £1 

*1 [Ct] <* K 2 t ' 2 H 0 2 

O2 A Of,! £2 

E; ^ t : k 2 t 2 (AA. t 2 [&] t[£l]) H O', 0' 2 


ITyC_Infer 


We are checking that t has type n 2 . First, Bake synthesizes t’s type K\, producing 
unification telescope O. We then must, as described in Section 6.4.3, deeply skolemize 
k 2 . Pulling out the quantifiers in k 2 (according to the f^ re judgment) gives us IIA. n 2 . 
We then generalize Q by A. It is this generalization step that allows the solver to solve 
unification variables in O with skolems in A and allows the example from Section 
6.4.3 to be accepted. Having generalized, we then do the subsumption check. We now 
must generalize 0 2 , the output unification telescope from the subsumption check, as 
0 2 might refer to skolems bound in A. 
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Once again, the key interesting part of this rule is the first generalization step. It 
is not necessary to do this in order to get correct elaboration, but the analysis in my 
prior work [33, end of Section 6.1] suggests that this is necessary in order to have 
principal types. 

6.6.3 case expressions 

We see in Figure 6.6 on page 160 that there are two judgments for checking case 
alternatives. These correspond to the two rules for checking case expressions, one for 
synthesis (ITy_Case) and one for checking (ITyC_Case). I refrain from including 
the actual rules here, as their myriad and ornate details would be distracting; the 
overly curious can see Appendix D for these details. 

As discussed previously (Sections 4.3.3 and 6.4), a case expression is treated 
differently depending on whether we can know its result type. In the case where 
we do not (ITy_Case), Bake invents a new unification variable /3 for the result 
type and checks each case alternative against it. This is why the bit judgment takes 
a result type, even though it is used during synthesis. After all, we do require all 
alternatives to produce the same result type. Producing the unification variable within 
each alternative would risk running into a skolem escape, whereby the result type 
might mention a variable locally bound within the alternative. It is simpler just to 
propagate the /? down into bit- The bit judgment, in turn, does not use the equality 
gotten from dependent pattern matching when checking alternatives. Recall that doing 
so during synthesis mode would cause trouble because the equality assumption would 
make the 0 unification variable untouchable when solving constraints emitted while 
processing the alternatives. 

On the other hand, the bite judgment is used from ITyC_Case, in checking mode. 
This judgment is almost identical to bit except that it allows the alternatives to make 
use of the dependent-pattern-match equality. 

6.6.4 Checking A-expressions 

Consider checking this expression: 

(A (f :: Int -A Int ) A f5) :: (Va. a A a) A Int (6.6.1) 

This expression should be accepted. The A takes a function over Ints and applies 
it. The type signature then says that the A should actually be applicable to any 
polymorphic endofunction. Of course, such a function can be specialized to Int, so all 
is well. Indeed, the expression above is accepted by GHC. 

The example above, however, is not dependent. Surprisingly, the intuition in the 
above paragraph does not generalize to the dependent case. Consider this (contrived) 
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example: 


(A (f :: Bool -4 Bool ) -4 P) :: II (g :: V a. a -4 a) -4 Proxy ’(g 5,g True ) (6.6.2) 

where we have 

data Proxy :: V k. k —> Type where 
P :: V k (a :: /r). Proxy a 
— equivalent to data Proxy a = P 

Once again, the annotation on the A argument is a specialized version of the argument’s 
type as given in the type signature. And yet, this expression must be rejected. 

One way to boil this problem down is to consider what type we check the expression 
P against. When we are checking P, we clearly have f:: Bool -4 Bool in scope. Yet 
the natural type to check P against is Proxy \g 5, g True), which mentions g, not 
f. Even if the names were to be fixed, we would still have the problem that g 5 is 
certainly not well typed if g has type Bool -4 Bool. We are stuck. 

Another way to see this problem is to think about elaborating the subsumption 
judgment. In example (6.6.1), type inference will check whether V a. a -4 a < Int -4 Int. 
When it discovers that this is true, the subsumption algorithm will also produce a 
function that takes something of type V a. a —> a to something of type Int -4 Int. If the 
expression in example (6.6.1) is applied to an argument (naturally, of type V a. a -4 a), 
then this conversion function readies the argument to pass to the A-expression. 

In example (6.6.2), however, we need conversions both ways. We still need the 
conversion from V a. a -4 a to Bool -4 Bool, for exactly the same reason that we need 
it for example (6.6.1). We also need the conversion in the other direction (in this case, 
the impossible conversion from Bool -4 Bool to V a. a 4 a) when checking that P, 
with f :: Bool -4 Bool in scope, has type Proxy \g 5,g True), using g :: V a. a -4 a. 

The solution to this is to have two separate rules, one in the non-dependent case 
and one in the dependent case. Bake looks at the type being checked against (let’s 
call it t). If t uses its argument dependently, then Bake requires that the annotation 
on the A argument and the function type as found in r can be proved equal—that 
is, that there is a coercion between them. Otherwise, we use subsumption, just as in 
example (6.6.1). You can view the two rules in Section D.5; as usual, the rules are a 
bit cluttered to present here. 


6.7 Program elaboration 

Up until now, this chapter has focused more on the gate-keeping services provided by 
Bake, preventing ill formed programs from being accepted. In this section, we will 
discuss elaboration, the process of creating the PlCO program that corresponds to an 
input Haskell program. Let’s look in particular on the highest levels of elaboration, 
processing Haskell declarations and programs. See Figure 6.8 on the next page for the 
two judgments of interest. 
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E; T fr ec | decl x : k := r\ Check a Haskell declaration. 


E; T l^| v -w A; © 

t' = AA. (t[0]) k! = PinfA. («[0]) 
E; T ^ ed x t -w x : k' r' 


IDecl_Synthesize 


E; r s cr H fli 

E; Rel(r) Rel^) ^ A i; 0, 

O' = IJinfAi. (cr[0i]) 

E; T lj| t : o' ^ t H 

E; r ^iv r ^2 0 ; 02 

r' = r[0 2 ] _ 

E; T ^ ed x :: s := t x : o' := t' 


IDecl_Check 


E; T f^-og prog r ; ; 9 | Check a Haskell program. 


E; T ^ rog 0 w 0; 0 


IProg_Nil 


E; T ^ ed decl x : k : = r 
E; T, xiReiR, c:x ~ r f^ r0 g prog V; 9 
E; T ^ rog decl; prog x: Re |«;, c:x ~ r, P; (t/x, (t) /c) o 9 


IProg_Decl 


Figure 6.8: Elaborating declarations and programs 

6.7.1 Declarations 

The f^eci judgment processes the two forms of declaration included in the Haskell 
subset formalized here: unannotated variable declarations and annotated variable 
declarations. It outputs the name of the new variable, its type k and its value r. 
Note that the environment used in ^ ed is E; V. with a context containing only PlCO 
variables, no unification variables. These are top-level declarations only. 

Rule IDecl_Synthesize simply ties together the pieces of using the synthesis 
judgment and the solver. Note that the definitions of r' and k' in the rule generalize 
over the telescope A produced by the solver, and that the n-type formed marks the 
binders as inferred, never specified. 

Rule IDecl_ Check is a bit more involved. It first must check the type signature 
using the judgment, to make sure s it is a well formed polytype. This process might 
emit constraints, and we must solve these before tackling the term-level expression. 
This would happen, for example, in the type V a. Proxy a —>• (), as a’s kind is 
unspecified. The solver may produce a telescope Ai to generalize by. In our example, 
this telescope would include /c:| rre |Type, the type of a. Having sorted out the type 
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signature, we can now proceed to the expression t, which is checked against o' the 
generalized PlCO translation of the user-written polytype s. We must solve once again. 
In this invocation of the solver, we insist that no further generalization be done because 
the user has already written the entire type of the expression. This decision is in 
keeping with standard Haskell, where a declaration like 

bad :: a —>• String 
bad x = show x 

is rejected, because accepting the function body requires generalizing over an extra 
Show a constraint. 

6.7.2 Programs 

The elaboration of whole programs is generally straightforward. This algorithm appears 
in Figure 6.8 on the preceding page. The judgment E; F jy rog prog F'; 9 produces as 
output an extension to the context, T', as well as a closing substitution 6 which maps 
the newly bound variable to its definition. (Recall that this formalization of Bake 
ignores recursion; thus no variable can be mentioned in its own declaration.) 

The one non-trivial rule, IProg_Decl, checks a declaration and then incorporates 
this declaration into the context T used to check later declarations. There is one small 
twist here, though: because declared variables can be used in types as well as in terms, 
we wish the typing context to remember the equality between the variable and its 
definition. This is done via the coercion variable c included in the context in the 
second premise to IProg_Decl. 


6.8 Metatheory 

This chapter has explained the Bake algorithm in some detail, but what theoretical 
properties does it have? A type inference algorithm is often checked for soundness 
and completeness against a specification. However, as argued by Vytiniotis et al. [99, 
Section 6.3], lining up an algorithm such as Bake against a declarative specification 
is a challenge. Instead of writing a separate, non-algorithmic form of Bake, I present 
three results in this section: 

• I prove that the elaborated PlCO program produced by Bake is indeed a well 
typed PlCO program. This result—which I call soundness—marks an upper limit 
on the set of programs that Bake accepts. If it cannot be typed in PlCO, Bake 
must reject. 93 

93 I do not prove a correspondence between the Haskell program and the Pico program produced 
by elaboration. It would thus theoretically be possible to design Bake to accept all input texts and 
produce a trivial elaborated program. But that wouldn’t be nearly as much fun, and I have not done 
so. 
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• In two separate subsections, I argue that Bake is a conservative extension 
both of the OutsideIn algorithm and the SB algorithm of Eisenberg et al. [33]. 
That is, if OutsideIn or SB accepts a program, so does Bake. This results 
suggests that a version of GHC based on Bake will accept all Haskell programs 
currently accepted. These arguments—I dare not quite call them proofs—are 
stated in less formal terms than other proofs in this dissertation. While it is likely 
possible to work out the details fully, the presentation of the other systems and 
of Bake/Pico differ enough that the translation between the systems would 
be fiddly, and artifacts of the translation would obscure the main point. The 
individual differences are discussed below. 

These conservativity results provide a lower bound on the power of Bake, 
declaring that some set of Haskell programs must be accepted by the algorithm. 

The results listed above bound the power of the algorithm both from below and 
from above, serving roughly as soundness and completeness results. It is left as future 
work to define a precise specification of Bake and prove that it meets the specification. 

6.8.1 Soundness 

Here is the fundamental soundness result: 

Theorem (Soundness of Bake elaboration [Theorem E.44]). If E btx T ok and 
E; T l^ rog prog T'; 9, then: 

i. e iy tx r, r ok 

E; T bubst 9 : T 
3. dom(prog) C dom(r / ) 

This theorem assumes that the starting environment is well formed E f^ tx E ok and 
that Bake accepts the source language program prog. In return, the theorem claims 
that the context extension V is well formed (assuming it is appended after T), that 
the substitution 9 is a valid closing substitution (see below), and that indeed the new 
context T' binds the variables declared in prog. 

Closing substitutions are recognized by the new judgment fi ubs t, which appears in 
Figure 6.9 on the next page. (Note the turnstile b; this is a pure PlCO judgment with 
no unification variables in sight.) It uses a new notation 9\% which restricts the domain 
of a substitution 9 to operate only on the variables ~z. Informally, E; T bubst 9 : A holds 
when the substitution 9 eliminates the appearance of any of the variables in A. Here 
is the key lemma that asserts the correctness of the judgment: 

Lemma (Closing substitution [Lemma E.30]). If E; T f^ u bst 0 '■ A and E; T, A, T' b J, 
then E;r,r / [6>| dom ( A )] b t7[0|dom(A)]- 
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E; T bubst 0 : A | u 9 substitutes the variables in A away.” 


fi ubst 0:0 


Subst_Nil 


E;Tb y a[6\ : k 


£; r bubst 0 

: A[0| a ] 

E;T bubst 0 : 

a: Re iR, A 

E; Rel(T) by 

a[9] : k 

T bubst 0 : 

Ap|a] 

E; T bubst 0 : a:i rre |R, A 

E; Rel(T) 

bo c[0] : (j) 

E; T bubst 

e:A[9\ c ] 


E; T bubst # : c:cj), A 


Subst_TyRel 


Subst_TyIrrel 


SUBST_CO 


Figure 6.9: Validity of closing substitutions 
Here, I use a notation where J stands for a judgment chosen from by; bo, brop, bit, 

bee, btx, Or b- 

The use of bubst i n the conclusion of the elaboration soundness theorem means that 
the variable values stored in 9 actually have the types as given in T'. 

Naturally, proving this theorem requires proving the soundness of all the individual 
judgments that form Bake. These proofs all appear in Section E.9. 

6.8.1.1 Adapting lemmas on b to b 

The first step in establishing the soundness result is to ensure that the structural 
lemmas proved for b judgments still hold over the b judgments. While doing this 
for the definitions as given does not pose a challenge, it is in getting these proofs to 
work that all of the complications around unification variables (to wit, zonkers and 
generalizers) arise. 

Relating the two sets of judgments is accomplished by this key lemma: 

Lemma (Extension [Lemma E.3]). E; T b J if and only if E; T b J. 

Note that the context must contain only PlCO variables, never unification variables. 
This fact is what allows the larger E; T b J to imply the smaller E: Y b J. 
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E; 'I' ^ © : Q\ “0 zonks all the unification variables in Q .” 


E;'!' ^ 0 : 0 


ZONK_NlL 


E; 4/, A t : k 

E;^ f= 0 : Q[Vdom (A). t/cc] 

E; 4/ Vdom(A).r/a,© : a: Re |VA.R,G 

E;Rel(#, A) (f y r : k 
E;^ k © : ft[Vdom(A).T/a] 

E; 'll t= Vdom(A). r/a, © : a :i rre i V A .k, Q 


Zonk_TyVarRel 


Zonk_TyVarIrrel 


E; \k, A 7 : (f 
E;tf^0 : n[Vdom(A). 7 /t] 

E; 'F ^ Vdom(A). 7 /t, 0 : t : V A.</>, fi 


Zonk_CoVar 


Figure 6.10: Zonker validity 

6.8.1.2 Soundness of the solver 

The solver E; \F t^| v fl A; 0 produces a generalization telescope and a zonker. In 
order to define a correctness property for this solver, we first need a judgment that 
asserts the validity of the zonker. This judgment appears in Figure 6.10. The judgment 
is quite similar to the judgment classifying closing substitutions (fi ubs t, in Figure 6.9 
on the previous page), but it deals also with the complexity of having unification 
variables quantified over telescopes. 

Naturally, we must require that the solver produce a valid zonker. We also require 
that the zonker be idempotent, as that is a necessary requirement to prove the zonking 
lemma, below. Here is the soundness property we are assuming of the solver. Note 
that this property is the only one we need to prove soundness of elaboration. 

Property (Solver is sound [Property E.24]). If E ^ tx \F, tt ok and E; 4/ l^| v Q -w A; 0, 
then 0 is idempotent, E f^ tx 4/, A ok, and E; A ^ © : Q. 

Lemma (Zonking [Lemma E.23]). If 0 is idempotent, E; \F ^ © : O, and E; $,Q,AN 
J, then E;tf,A[0] NJ[©]. 

6.8.1.3 Soundness of generalization 

The following lemma asserts the correctness of the generalization judgment: 

Lemma (Generalization [Lemma E.35]). Iffl A Q'; £ and E; \F, A, Q N J, then 
E;|r,fi',ANJ[^]. 

The proof of this lemma relies on the following smaller lemma (and its counterpart 
for coercion variables): 
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Lemma (Generalization by type variable [Lemma E.32]). 7/E; 4/, A, a : P V A '.k, 4/' t= 
J, then E; 4>, a : p V A, A'.k, A, 4/'[a; i-> dom(A)] N J[a (->• dom(A)]. 

6 . 8 .1.4 Soundness lemmas for individual judgments 

Lemma (Instantiation [Lemma E.36]). If E; 4/ tf y r : k and ^ st k ^ if;K' -\£L, then 
E; \b, 0 if y rtf : k' and k' is not a H-type with a binder (with visibility v 2 ) such that 
v 2 < v. 

Lemma (Scrutinee position [Lemma E.38]). If E; 4/ hjy t : k and E; 4/ b£ rut alt; k 
7 ; A; H r H Q, then E; 4>, G ^ r > 7 : IIA. H't and E; Rel(4>, H'r : Type. 
Lemma (Prenex [Lemma E.40]). If E; Rel(4>) hjy k : Type and f^ re k A then 
E; 4/ t : ILz;:R e |(nA. k'). k. 

Lemma (Subsumption [Lemma E.41]). Assume E; Rel(4/) by k% : Type and 
E; Rel(4/) hjy k 2 : Type. If either 

1. K\ <* k 2 t H fl 7 or 

2. < K 2 T H fl 7 

then E; 4/, 0 r : Ila^Reifiq. k 2 . 

Lemma (Type elaboration is sound [Lemma E.42]). 

1. If any of the following: 

(a) E t^ tx 4/ ok and E; $ ^ t ^ r : k H fi 7 or 

(b) E ^ tx 4/ ok and E; 4/ 1^ t r : k H fl 7 or 

(c) E; Rel(4>) hjy n : Type and E; 4/ t : k t H Q, or 

(d) E; Rel(4>) hjy k : Type and E;f Iti/t^rHO, 
then E; 4/, Q r : k. 

2. If E ^ tx 4/ ok and E; 4/ ^ s a H fl 7 then E; Rel(4>, G) hf y a : Type. 

3. If E; 4/ hjy Ti : IGaipKq. k 2 and E; 4/; p t 2 : «q ip 2 ; r 2 H II, t/ien E; 4/, hjjy 

Ti^ 2 : k 2 [t 2 /o]. 

//E; Rel(4>) hf y k : Type, E; 4/ hf y t 0 : IIA. Hr, E; Rel(4>) hfy H r : Type, and 

E; 4/; HA. Hr; To litt alt : n alt H G, then E; 4/, G; HA. Hr tf° t alt : k. 

5. If E;Rel(4>) hf y n, : Type, E; 4/ hf y t 0 : IIA. H r, E; Rel(4>) hfy Hr : Type, and 

E; 4/; k 0 ; tq fit tc alt : k alt H fl 7 then E; 4/, 0; n 0 if° t alt : k. 

6. If E ^ tx 4/ ok and E; 4/ l^qvar a : k; v H then E; Rel(4>, ft) hjy k : Type. 

7. If E ^ tx 4/ ok and E; 4/ ^ aqvar a : k H 0 7 t/ien E; Rel(47, O) if y k : Type. 

£. //E; 4/ hfy r 0 : and E; 4/ aqvar : k a : k'; x.t H G, t/ien E; 47, O r[r 0 /x] : 
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OutsideIn construct 

Pico form 

Notes 

Axiom scheme 

Q 

f 

instances, etc.; implications are func¬ 
tions; type family instances are via 
unfoldings 

Given constraint 

Qg, Qr 

A 

constraints are named in PlCO 

Wanted constraint 

Qw 

fl 

we must separate wanteds & givens 


Figure 6.11: Translation from OutsideIn to PlCO 

6.8.2 Conservativity with respect to OUTSIDElN 

I do not endeavor to give a full accounting of the OutsideIn algorithm here, instead 
referring readers to the original [99]. I will briefly explain judgments, etc., as they 
appear and refer readers to Figure numbers from the original text. 

There are several mismatches between concepts in OutsideIn and in PlCO. Chief 
among these is that OutsideIn does not track unification variables in any detail. 
All unification variables (and type variables, in general) in OutsideIn have kind 
Type, and thus there is no need for dependency tracking. In effect, many judgments in 
OutsideIn are parameterized by an unwritten set of in-scope unification variables. We 
have no such luxury of concision available in Bake, and so there must be consideration 
given to tracking the unification variables. 

To partly bridge the gap between OutsideIn and Bake, I define encode which 
does the translation, according to Figure 6.11. encodeing a construct from the left 
column results in a member of the syntactic class depicted in the middle column. 

OutsideIn differentiates between algorithm-generated constraints C and user- 
written ones Q ; the former contain implication constraints. I do not discern between 
these classes, considering implication constraints simply as functions. I will use Q 
metavariables in place of OutsideIn’s C. 94 

A further difference between OutsideIn and Bake is that the latter is bidirectional. 
When OutsideIn knows the type which it wishes to assign to a term, it synthesizes 
the term’s type and then emits an equality constraint. In the comparison between the 
systems, we will pretend that Bake’s checking judgments do the same. 

The fact that I must change my judgments does not imperil the practical impact 
of the conservativity result—namely, programs that GHC accepts today will still be 
accepted tomorrow. GHC already uses bidirectional type-checking and so has already 
obviated the unidirectional aspect of OutsideIn. However, in order to make a formal 
comparisons between that published algorithm, it is helpful to restrict ourselves to a 
unidirectional viewpoint. 

A final difference is that Bake does elaboration, while OutsideIn does not. I 

94 This conflation of Q and C does not mean that Dependent Haskell is now required to implement 
implication constraints; it would be easy to add a post-type-checking pass (a “validity” check, in the 
vocabulary of the GHC implementation) that ensures that no constraints have implications. 
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shall use the symbol • to denote an elaborated type that is inconsequential in this 
comparison. 


6.8.2.1 Expressions 

Claim (Expressions [Claim E.45]). If T ^ t : k Q w under axiom set Q and 
signature E, then E; T, encode(Q) t • : k H o:i rre |Type, encode(Qw) where 
a = fuv(/c) U fuv(Qw)- 

This claim relates OutsideIn’s T \^' t : k Q w judgment (Figures 6 and 13 
from Vytiniotis et al. [99]) to Bake’s synthesis judgment. Note that the output 
£7 from Bake’s judgment must include both the wanteds (encode(Q w )) and also any 
unification variables required during synthesis (a). 

To argue this claim, we examine the different rules that make up OutsideIn’s 
judgment, using structural induction. The details appear in Section E.10. 

6.8.2.2 The solver 

Property (Solver). If Q; Q g ;a i f^ !v Q w Q r ; 0 where E and T capture the signature 
and typing context for the elements of that judgment, then 

E; T,encode(Q), encode(<5g) tiSiv ai:i rre iType. encode(Q w ) 

^IrreiType, encode(Q r )[a 2 /a 2 ]; a 2 /a 2 , 0, 

where the a 2 ore fresh replacements for the a; 2 which are free in Q r or unconstrained 
variables in 

This property is a bit more involved than we would hope, but all of the complication 
deals with Bake’s requirement of tracking unification variables more carefully than 
does OutsideIn. Underneath all of the faffing about with unification variables, the 
key point here is that Bake’s solver will produce the same residual constraint Q r as 
OutsideIn’s and the same zonking substitution 0. 

I do not try to argue this property directly, as I do not present the implemen¬ 
tation for the solver. However, this property shows a natural generalization of the 
solver in an environment that includes dependencies among variables. Indeed, GHC’s 
implementation of the solver already handles such dependency. 

6.8.2.3 Programs 

Claim (Bind). If P ^ t: k Q w and Q\ e; fu v(k) U fuv(Q w ) Qw Qr ; 0, then 
E; T, encode(Q) fed x:=t~*x: II| nf a:i rr eiType. (II| n fencode(Q r ). /c[0])[a/a] := t for 
some t , where a = fuv(/c[©]) U fuv(Q r ) and a are fresh replacements for the a. 

This claim relates OutsideIn’s Bind rule (Figure 12) to Bake’s IDecl_Syn- 
thesize rule. It is a consequence of the claim on expressions and the property above 
of the solver. 
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Claim (Conservativity over OutsideIn). If Q: Y ^ prog, prog contains no annotated 
bindings, and E captures the signature of the environment prog is checked in, then 
E; T, encode(Q) ^ rog prog T'; 9. 

This claim relates the overall action of the OutsideIn algorithm (Figure 12) to 
Bake’s algorithm for checking programs. It follows directly from the previous claim. 

Because of this, I believe that any program without top-level annotations accepted 
by OutsideIn is also accepted by Bake. 

6.8.3 Conservativity with respect to System SB 

Here, I compare Bake with the bidirectional algorithm (called SB) in Figure 8 of 
Eisenberg et al. [33]. That algorithm is proven to be a conservative extension both 
of Hindley-Milner inference and also of the bidirectional algorithm presented by 
Peyton Jones et al. [74], This SB algorithm, along with OutsideIn, is part of the 
basis for the algorithm currently implemented in GHC 8. 

Before we can successfully relate these systems, we must tweak both a bit to bring 
their approaches more in line with one another: 

• System SB assumes an ability to guess monotypes. This is evident, for example, 
in the SB_Abs rule, where an unannotated A-expression is processed and the 
monotype of the argument is guessed. Bake, of course, uses unification variables. 
I thus modify System SB to always guess a unification variable when it guesses. 
The modified rules are SB_Abs, SB_InstS, and SB_Var. 

• Because of the previous change, it is now unfair in rule SB_App to insist that 
the result of synthesis be a function type. Instead, the result of synthesizing the 
type of e\ is an arbitrary monotype, and the judgment is used to expand this 
out to a proper function type. Note that we do not make a similar change in 
SB_TApp; doing so would be tantamount to saying that a unification variable 
might unify with a type with an invisible binder, something we have forbidden. 
(See Section 6.10.1.3.) We similarly must modify SB_DAbs to allow for the 
possibility of a unification variable being checked against. 

• There is no convenient equivalent of integers in Bake; I omit the rule SB_Int. 

• Bake does not do let-generalization. I thus modify SB_Let and SB_DLet 
to use the lf b judgment instead of the generalizing judgment. 

• System SB skolemizes deeply in its checking judgment, while Bake skolemizes 
only shallowly. We thus move the prenex operation from SB_DeepSkol to 
SB _ Infer. I claim that this change does not alter the set of programs that 
System SB accepts, due to the fact that neither non-lNFER rule in the bb 
judgment interacts with Vs. 
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• Bake expends a great deal of effort tracking telescopes of unification variables, 
requiring the notion of a generalizer £. However, in the language supported by 
System SB, all type variables always have kind Type and so these telescopes are 
unnecessary. We thus simply ignore generalizers and the generalization judgment 
(which always succeeds, regardless). 

The theorem below also needs to relate a context T used in Bake with the more 
traditional context T used in System SB. In the claim below, I use \l/ « T to mean that 
all T has no coercion bindings, that all irrelevant bindings in T are of kind Type, and 
that no relevant bindings depend on any other. Furthermore, all unification variables 
bound in d' are absent from T. 

I can now make the following claim: 

Claim (Conservativity with respect to System SB [Claim E.47]). Assume 4/ « V. 

1. If T t => k, then E; f l;| t: fiH it. 

2. If r l-f b t =>- k, then E; |A t -w • : k H it. 

3. If T lib t 4= k, then E; d/ t : k • H Q. 

4■ If T l| b t 4= k, then S; d f t : • H Q. 

A detailed argument for this claim appears in Section E.ll. 

6.9 Practicalities 

I have designed Bake with an eye toward implementing this algorithm directly in 
GHC. This section discusses some of the practical opportunities and challenges in 
integrating Bake with the rest of GHC/Haskell. 

6.9.1 Class constraints 

In both PlCO and Bake, I conspicuously ignore the possibility of Haskell’s type classes 
and instances. However, this is because classes and instances are already subsumed by 
these formalizations’ handling of regular variables. 

Classes in Haskell are already compiled into record types that store the imple¬ 
mentations of methods, and instances are record values (often called dictionaries ) 
(Section 2.1). As PlCO supports datatypes, it also supports classes. Nothing about 
the type class system should matter at all in PlCO. Indeed, System FC as currently 
implemented in does not GHC 8 cares about type classes, to no ill effect. 

During type inference, on the other hand, we need to care a bit about classes and 
instances, because these are values that the type inference mechanism fills in for us. 
However, with Bake’s ability to distinguish visible arguments from invisible ones and 
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its orthogonal ability to work with variables of different relevances, the answer is right 
in front of us: an instance is simply an inferred, relevant argument. That’s it! These 
are handled in the following rule, part of the judgment that converts a user-written 
polytype into PlCO: 


E; \l/ t : Type r H fli 
E; \l>, S7i, $a: Re |T s a H fl 2 
f^2 ^ $a:R e iT 

E; ^ t =t s n| n f$a: Re ir. (a[£j) H fii, Q' 2 


IPtC _ Constrained 


This rule checks the constraint t, making sure it is well typed as a constraint (see 
Section 6.9.5) and then checks the rest of the type, assuming the constraint. The use 
of a $ sign in the name of the constraint ($a) is meant to convey that the variable $a 
cannot appear in the Haskell source. 

Note that “given” class constraints (that is, a user-written context on a function 
type signature) are also handled without any effort, as a member of a telescope that 
unification variables are quantified over. 

In contrast to the Bake constraint generation algorithm, the solver must treat 
instances separately and have a way of finding instances in the global set. However, 
this remains out of scope for this dissertation. 


6.9.2 Scoped type variables 

Scoped type variables in GHC/Haskell have an idiosyncratic set of rules detailing 
when variables are to be brought into scope [72], Consider the following two examples, 
where t is an arbitrary term: 

example 1 = (t:: V a. a ->• a) 
higherRank :: (V a. a A a) A () 
example 2 = higherRank t 

In example 1; the type variable a is in scope in t. In example 2 , however, a is not in 
scope. This is true despite the fact that, in both cases, Bake would check t against 
the same PlCO type. 

Instead of trying to track all of this in the constraint generation algorithm, however, 
Bake divides its pool of variable names into those names that can appear in a source 
program (a, b, x) and those that cannot ($o, $6, %x ) . When Bake must put a variable in 
the context that should not be available in Haskell, it uses the $a variant. Scoped type 
variables are explicitly brought into scope by A or A. It is thus up to the preprocessor 
which must introduce abstractions as necessary to bring the scoped type variables 
into scope; as this process is not type-directed, incorporated this into the preprocessor 
should not be a challenge. 
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Bake judgment GHC function 

ten matchExpectedFunTys 

terut matchExpectedTyConApp 

test toplnstantiate 

tee tcDeepSplitSigma Ty_ maybe 

<* tcSubTypeDS 

< tcSubType 

teog tcPolyBinds 


Figure 6.12: GHC functions that already implement Bake judgments 

6.9.3 Correspondence between BAKE and GHC 

The design of Bake is already quite close to that of GHC’s constraint-generation 
algorithm. Figure 6.12 lists correspondences between Bake judgments and functions 
already existent in GHC. 

Notably absent from Figure 6.12 are the main judgments such as te- These are 
implemented in GHC via its tcExpr function, which handles both directions of the 
bidirectional type system at the same time through its use of expected types, a 
mechanism where the synthesis judgment is implemented by checking against a hole — 
essentially, a unification variable that can unify with a polytype. A full accounting of 
GHC’s expected types and holes is out of scope here, but there should be no trouble 
adapting Bake’s bidirectional algorithm to GHC as previous bidirectional algorithms 
have been adapted. 

6.9.4 Unification variables in GHC 

The GHC implementation takes a very different approach to unification variables 
and zonking than does Bake. A GHC unification variable (called a metavariable in 
the source code) is a mutable cell. The solver fills in the mutable cells. Though the 
implementation details differ a bit, the same is currently true for unification coercion 
variables (called coercion holes in GHC)—they are still mutable cells. The zonking 
operation walks through a type (or coercion or expression) and replaces pointers to 
mutable cells with the cells’ contents. On the other hand, Bake’s treatment of filling 
in unification variables requires building up an explicit zonker 0; in effect, the implicit 
substitution GHC builds in the heap using mutable cells is made explicit in Bake. 

Another key difference between GHC and my formalization (and every other) is 
that GHC variables track their own kinds. The implementation does track a context 
used in looking up user-written variable occurrences, but no context is needed to, say, 
extract a type’s kind from the type itself. Because of this design, GHC does not need 
to track unification telescopes, even though GHC 8 already can have arbitrarily long 
chains of variables that depend on others. Instead, the solver takes (essentially) the 
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set of unification variables to solve for. Dependency checking is done after the fact as 
a simple pass making sure all variables in kinds are in scope. 

A further consequence of GHC’s design is that there is no need for the concept of 
generalizers £ as I have described. Unification variable occurrences are not, in fact, 
applied to vectors. Along with the fact that GHC does not track contexts, it also uses 
stable names powered by a enumerable collection of Unique s. We thus do not have to 
worry about arbitrary o-renaming during constraint generation and solving. Taken 
together, the need for generalizers is lost, and thus the generalization operation 
disappears. 

6.9.5 Constraint vs. Type 

Haskell includes the kind Constraint that classifies all constraints; we thus have 
Show :: Type —>• Constraint. However, due to the datatype encoding of classes and the 
dictionary encoding of instances, PlCO manipulates constraints just as it does ordinary 
types. For this reason, PlCO makes no distinction between Constraint and Type. This 
choice follows GHC’s current practice, where Constraint and Type are distinct in the 
source language but indistinguishable in the intermediate language. This design has 
some unfortunate consequences; see GHC ticket #11715 for a considerable amount of 
discussion. 

Extending the language with dependent types is orthogonal to the problems 
presented there, however. For simplicity, Bake as described here does not recognize 
Constraint, putting all constraints in the kind Type with all the other types. 


6.10 Discussion 

6.10.1 Further desirable properties of the solver 

Thus far, I have stated only one property (in Section 6.8.1.2) that the solver must 
maintain, that it must output a valid zonker. However, it is helpful to describe further 
properties of the solver in order to make type inference more predictable and to 
maintain the properties stated by Vytiniotis et al. [99], such as the fact that all 
inferred types are principal and that the solver makes no guesses. The full set of extra 
properties are listed in Figure 6.13 on the next page. 

6.10.1.1 Entailment 

These properties are stated with respect to an entailment relation, defined as follows: 

Definition (Entailment). We say that an environment E; T entails a telescope A, 
written E; \I/ |(= A, if there exists a vector if such that E; \l/ ^ ec if : A. 
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Property 6.1 (Solver is guess-free). //E; \1/ (^| v A; 0, then E;\k,n ||= A ,£ e , 
where = {_:a ~ t \/z.r/a e 0 } is the equational constraint induced by the 
zonker 0 . 

The above property is adapted from Vytiniotis et al. [99, Definition 3.2 (PI)]. 

Property 6.2 (Solver avoids non-simple types). If E; T l^| v Q A; 0 and\/z.r/a e 
0 , then t is a simple type, with no invisible binders (at any level of structure) and no 
dependency. 

Property 6.3 (Solver does not generalize over coercions). If E; \P l^| v Q A;0, 
then A binds no coercion variables. 


Figure 6.13: Additional solver properties 

As this section expands upon the ideas from Vytiniotis et al. [99], it is necessary to 
check whether this definition of entailment satisfies the entailment requirements from 
that work. These requirements are presented in Figure 6.14 on the following page. 

All of this properties are easily satisfied, except for property (R 8 ) (both components) 
which requires congruence. As explored in some depth in Section 5. 8 .5.3, PlCO simply 
does not have this property. However, that same section argues that equality in PlCO 
is “almost congruent”, suggesting that the equality relation truly is congruent in the 
absence of coercion abstractions. The proof that the OutsideIn algorithm infers 
principal types does require property R 8 [99, Theorem 3.2], and so it is possible that 
Pico’s lack of congruence prevents Bake from inferring principal types. The details 
have yet to be worked out. 

6.10.1.2 A guess-free solver 

One of the guiding principles I set forth at the beginning of this chapter is that the 
algorithm and solver be guess-free. We thus must assert that the solver is guess-free, 
an important step along the way to the proof of principal types in Vytiniotis et al. 
[99]. See Property 6.1. 

6.10.1.3 Solver does not introduce impredicativity 

An important but previously unstated property is that that solver must not set a 
unification variable to anything but a simple type, one with no invisible binders nor 
dependency. (Such types are sometimes called r-types, referring to the t ja split in the 
typical presentation of the Hindley-Milner type system.) In the context of Dependent 
Haskell, impredicativity has perhaps an unusual definition: no type variable is ever 
instantiated with a non-simple type. For this to hold, however, we must make sure 
that this property extends to unification variables as well, as those are sometimes used 
to instantiate regular variables. 
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Reflexivity 

E; 4>, A IN A 

m 

Transitivity 

E; \P, Ai IN A 2 A E; T, A 2 IN A 3 =*> E; \P, Ai IN A 3 

(R2) 

Substitution 

E; , A 1? V' IN A 2 A E; 4/ ff ubst 6 : A 1 

=> E;tf,^'[0] IN A 2 [0] 

(R3) 

Type eq. reflexivity 

E; \P hf y r : k =>• E; \P IN _:r ~ r 

(R4) 

Type eq. symmetry 

E; \P IN _:ti ~ r 2 =>• E; \P IN _:r 2 ~ Ti 

(R5) 

Type eq. transitivity 

E; IN _:ti ~ t 2 A E; 4/ lfe; w :r 2 ~ t 3 

=► E; 4/ IN _:r, ~ r 3 

(R6) 

Conjunctions 

E; 4/ IN A 3 A E; 4/ IN A 2 E; 4/ IN A 3 , A 2 

(R7) 

Substitutivity 

E; 4/ IN _:Ti ~ t 2 A E; 4>, a: Re i«:o 

E;^ IN _:t[ti/ a] ~ r[r 2 /a] 

(R8a) 


E; Rel(4>) IN _:n ~t 2 AE; 4^, a:i rre i«:o k y r : k 

E;^ IN _:r[ri/a] ~ r\r%/a\ 

(R8b) 


Figure 6.14: Required properties of entailment, following [99, Figure 3] 


Solving unification variables with simple types is also important in the context 
of the theory around principal types developed in my prior work [33]. Specifically, 
we must ensure that there are no invisible binders that are hidden underneath a 
unification variable. By forbidding filling a unification variable with a non-simple type, 
we have achieved this goal. See Property 6.2. 

6.10.2 No coercion abstractions 

In stating that PlCO supports type erasure (Section 5.11), I admit that type erasure 
does not mean that we can erase coercion abstractions or applications, even though 
we can erase the coercions themselves. Nevertheless, I argue that PlCO can claim to 
support full type erasure because Bake never produces a PlCO program that evaluates 
to a coercion abstraction. To support this claim, we can look at the elaborated program 
produced by Bake and where coercion abstractions can be inserted: 

Around subsumption: Three rules extract out a telescope of binders using the ^ re 
judgment and then use these binders in the elaboration. If the telescope includes 
a coercion binder, the elaboration will include a coercion abstraction. However, 
I am arguing that there should be no coercion binders there in the first place, so 
we can handle this case essentially by induction. (Rules affected: ITyC_Infer, 
rules in the ^ re judgment, and ISub_DeepSkol) 

During generalization after running the solver: If the solver produces a tele¬ 
scope that binds coercions, Bake will similarly include a coercion abstract in its 
elaboration. We must thus assert Property 6.3. This property is not as restrictive 
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as it may seem, as the solver may still abstract over a class constraint whose 
instances store a coercion . 95 (Rule affected: IDecl_Synthesize) 

Elaborating case alternatives: When elaborating a case alternative, coercion ab¬ 
stractions are inserted. This is necessary for two reasons: 

• GADT equalities can be brought into scope in a case alternative. These 
are bound by coercion abstractions. 

• The dependent-pattern-match equality (Section 4.3.3) must be brought 
into scope by a coercion abstraction. 

However, when a case expression is evaluated (by evaluation rule S_Match), 
these coercion abstractions will be applied to arguments and thus cannot be the 
final value of evaluating the outer PlCO expression. (Rules affected: IAlt_Con, 
IAltC_Con) 

These are the only Bake rules that can include a coercion abstraction in their 
elaborated types. I thus conclude that type erasure is valid, with no possibility of 
having evaluation be stuck on a coercion abstraction. 

6.10.3 Comparison to Gundry [37] 

The Bake algorithm presented here is very similar to the type inference algorithm 
presented by Gundry [37, Chapter 7]. Here I review some of the salient differences. 

• Gundry includes both a non-deterministic elaboration process and a deterministic 
one, proving that the deterministic process is sound with respect to the non- 
deterministic process (at least, in the absence of case). I have omitted a non- 
deterministic version of the algorithm, instead using the soundness of the resultant 
PlCO program to set an upper limit on the programs that Bake can accept. 

• Gundry’s inch source language and his evidence intermediate language have 
two forms of case statement: one for traditional, non-dependent pattern match¬ 
ing; and one for dependent pattern matching. Bake chooses between these 
possibilities using the difference between checking and synthesis modes. 

• While Gundry uses two separate judgments in synthesis mode, he uses only one 
checking judgment. The need for two checking judgments here is an innovation 
that derives from the need for principal types, as explored in my prior work [33]. 

• The inch language does not allow annotations on the binders of a A-abstraction 
and so Gundry did not encounter the thorny case detailed in Section 6.6.4. 

95 For example, the Haskell equality constraint ~ is such a class, distinct from the primitive equality 
operator in Pico. In the terminology of Vytiniotis et al. [100], the Haskell equality is lifted while the 
Pico equality is unlifted. 
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• Gundry’s approach to delayed instantiation for function arguments follows 
along the lines of Dunfield and Krishnaswami [24], using an auxiliary judgment 
to control function application. While Bake has its judgment, which is 
superficially similar, Bake’s judgment can only handle one argument at a time. 

• Gundry’s algorithm does not do deep skolemization. It would thus not be 
backward compatible with GHC’s current treatment of higher-rank types. 

• Gundry gives more details about the solver in his algorithm [37, Section 7.5.1]. 
However, this solver is a novel algorithm that remains to be implemented. Instead, 
Bake targets the OutsideIn solver. Nevertheless, I do not think it would be 
hard for Gundry’s general approach to target OutsideIn, as well. 

• As a point of similarity, Gundry’s and Bake’s treatment of unification variables 
are very closely aligned. This is not actually intentional—after reading Gundry’s 
approach, I believed I could make the whole treatment of unification variables 
much simpler. Yet despite a variety of attempts, I was unable to make the 
basic lemmas that hold together a type system (e.g., substitution, regularity) go 
through without something as ornate as we have both used. I would love to see 
a simpler treatment in the future, but I do not hold out much hope. 

6.11 Conclusion 

This chapter has presented Bake, a type checking / inference / elaboration algorithm 
that converts type-correct Dependent Haskell types and expressions into PlCO. It is 
proven to produce type-correct PlCO code, and it is designed in the hope of supporting 
principal types. Formulating a statement and proof of principal types in Bake is 
important future work. 

This algorithm is also designed to work well with GHC’s existing type checker 
infrastructure, and in particular, its constraint solver. It is my hope and plan to 
implement this algorithm, quite closely to how it is stated here, in GHC in the near 
future. 
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Chapter 7 

Implementation 


This chapter reviews a number of practical issues that arise in the course of imple¬ 
menting the theory presented in this dissertation. Perhaps the most interesting of 
these is that the function that computes equality in GHC does not simply check for 
ct-equivalence; see Section 7.2. 

7.1 Current state of implementation 

As of this writing (August 2016), only a portion of the improvements to Haskell 
described in this dissertation are implemented. This section describes the current state 
of play and future plans. 

7.1.1 Implemented in GHC 8 

The language supported by GHC 8 is already a large step toward the language 
in this dissertation. The features beyond those available in GHC 7 are enabled by 
GHC’s TypelnType extension. I personally implemented essentially all aspects of this 
extension and merged my work in with the development stream. I have had feedback 
and bug reports from many users, 96 indicating that my new features are already 
gaining traction in the community. Here are its features, in summary: 

• The core language is very closely as described in my prior work [105]. 

• The kind of types * is now treated as described in Section 7.4. 

• Types and kinds are indistinguishable and fully interchangeable. 

• Kind variables may be explicitly quantified: 


96 According to the GHC bug tracker, 19 users (excluding myself) have posted bugs against my 
implementation. 
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data Proxy :: V k. k —» Type where 
Proxy :: V k (a :: k). Proxy a 


• The same variable can be used in a type and in a kind: 

data T where 

MkT :: V k (a :: k). k —> Proxy a —>• T 


• Type families can be used in kinds. 

• Kind-indexed GADTs: 

data G :: V k. k —>• Type where 
Glnt :: G Int 
G Maybe :: G Maybe 

data (:«:) :: V ki k 2 . k x — >• k 2 —t Type where 
HRefl :: aa 


• Higher-rank kinds are now possible: 

class HTestEquality (f :: V k. k -A Type) where 

hTestEquality :: V ki k 2 (a :: ki) (6 :: k 2 ). f a —>• f b —>• Maybe (a:«: h) 
instance HTestEquality TypeRep where — from Section 3.2.2 
hTestEquality = eqT 


• GADT data constructors can now be used in types. 

• The type inference algorithm used in GHC over types directly corresponds to 
those rules in Bake that deal with the constructs that are available in types 
(that is, missing case, let, and A). This algorithm in GHC is bidirectional, as is 
Bake. 

7.1.2 Implemented in singletons 

Alongside my work implementing dependent types in GHC, I have also continued 
the development of my singletons package [29, 30]. This package has some enduring 
popularity: it has over 7,000 downloads, 31 separate users reporting bugs, is the 
primary subject of several blog posts 97 and has even made its way into a textbook on 
Haskell [81, Chapter 13]. The singletons package uses Template Haskell [83], GHC’s 

97 Here are a sampling: 
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meta-programming facility, to transform normal term-level declarations into type-level 
equivalents. 

I use my work in singletons as a proof-of-concept for implementing dependent types. 
My goal with the dependent types work is to make this package fully obsolete. In the 
meantime, it is an invaluable playground of ideas both for me and other Haskellers 
who do not wish to wait for dependent types proper. 

Because of its function as a proof-of-concept, I include here a list of features 
supported by singletons. By their support in the library, we can be confident that 
these features can also be supported in GHC without terrible difficulty. The singletons 
currently supports code using the following features in types: 

• All term-level constructs supported by Template Haskell except: view patterns, 
do, list comprehensions, arithmetic sequences. (Template Haskell does not 
support GHC’s arrow notation.) The library specifically does support case, let 
(including recursive definitions) and A-expressions. See my prior work for the 
details [29], 

• Unsaturated type families and the distinction between matchable and unmatch- 
able arrows 

• Type classes and instances 

• Constrained types 

• Pattern guards 

• Overloaded numeric literals 

• Deriving of Eg, Ord , Bounded, and Enum 

• Record syntax, including record updates 

• Scoped type variables 

The latest major effort at improving singletons targeted GHC 7, though the library 
continues to work with GHC 8. I am confident more constructs could be supported 
with a thorough update to GHC 8—in particular, do-notation cannot be supported in 
GHC 7 because it would require a higher-kinded type variable. Such type variables 
are fully supported in GHC 8, and so I believe singletons could support do-notation 

• https://www.schoolofhaskell.com/user/konn/prove-your-haskell-for-great-safety/ 
dependent-types-in-haskell 

• https://ocharles.org.uk/blog/posts/2014-02-25-dependent-types-and-plhaskell.html 

• http://lambda.jstolEirek.com/2014/09/promoting-functions-to-type-families-in-haskell/ 

• https://blog.jle.im/entry/practical-dependent-types-in-haskell-l.html 

all by different authors—not to mention my own posts. 
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and list/monad comprehensions relatively easily now. However, I wish to spend my 
implementation efforts on getting dependent types in Haskell for real instead of faking 
it with singletons, and so may not complete these upgrades. 

7.1.3 Implementation to be completed 

There is still a fair amount of work to be done before the implementation of dependent 
types in Haskell is complete. Here I provide a listing of the major tasks to be completed 
and my thoughts on each task: 

• Implement PlCO as written in this dissertation. The biggest change over the 
current implementation of GHC’s intermediate language is that PlCO combines 
the grammar of types and of terms. The current intermediate language already 
supports, for example, heterogeneous equality and the asymmetric binding 
coercion forms (Section 5.8.5.1). While combining the internal datatypes for 
types and terms will be the furthest reaching change, I think the most challenging 
change will be the addition of the many different quantifier forms in PlCO (with 
relevance markers, visibility markers, and matchability markers). 

• Combine the algorithms that infer the types of terms and the kinds of types. 
Currently, GHC maintains two separate, but similar, algorithms: one that type- 
checks terms and one that kind-checks types. These would be combined, as 
prescribed by Bake. I expect this to be a simplification when it is all done, 
as one algorithm will serve where there is currently two—and both are quite 
complex. 

• Interleave type-checking with desugaring. Currently, GHC maintains two separate 
phases when compiling terms: type-checking ensures that the source expression 
is well typed and also produces information necessary for elaboration into its 
intermediate language. Afterwards, GHC desugars the type-checked program, 
translating it to the intermediate language. Desugaring today is done only after 
the whole module is type-checked. However, if some declarations depend on 
evaluating other declarations (because the latter are used in the former’s types), 
then desugaring and type-checking will have to be interleaved. I do not expect 
this to be a challenge, however, for two reasons: 

- Type-checking and desugaring are already interleaved, at least in types. 
Indeed, the kind checker for types produces a type in the intermediate 
language today, effectively type-checking and desugaring all at once. 

- Type-checking happens by going in order through a sequence of mutually 
recursive groups. One expression cannot depend on another within the same 
group, and so we can just process each group one at a time, type-checking 
and then desugaring. 
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• The source language will have to be changed to accept the new features. To be 
honest, I am a little worried about this change, as it will require updating the 
parser. Currently, the parsers for types and expressions are separate, but this 
task would require combining them. Will this be possible? I already know of one 
conflict: the ’ used in Template Haskell quoting (which made a brief appearance 
in Section 3.1.3.2) and the ’ used in denoting a namespace change. Both of these 
elements of the syntax are pre-existing, and so I will have to find some way of 
merging them. 

At this point, I do not foresee realistically beginning these implementation tasks 
before the summer of 2017. If that process goes swimmingly, then perhaps we will see 
Dependent Haskell released in early 2018. More likely, it will be delayed until 2019. 

During the process of writing this dissertation, I worked on merging my implemen¬ 
tation of TypelnType into the GHC main development stream. This process was much 
harder than I anticipated, taking up two more months than expected, working nearly 
full-time. I am thus leery of over-promising about the rest of the implementation 
task embodied in this dissertation. However, my success in emulating so many of 
the features in Dependent Haskell in singletons gives me hope that the worst of the 
implementation burden is behind me. 

Despite not having fully implemented Dependent Haskell, I still have learned much 
by implementing one portion of the overall plan. The rest of this chapter shares this 
hard-won knowledge. 


7.2 Type equality 

The notion of type equality used in the definition of PlCO is quite restrictive: it is 
simple cc-equi valence. This equality relation is very hard to work with in practice, 
because it is not proof-irrelevant. That is, lntt> (Type) ^ Int. This is true despite the 
fact that the ~ relation is proof-irrelevant. 

The proof-relevant nature of = poses a challenge in transforming PlCO expressions 
into other well typed PlCO expressions. This challenge comes to a head in the unifier 
(Section 7.3) where, given t\ and t 2 , we must find a substitution 9 such that T\ = r 2 . 
Unification is used, for example, when matching class instances. However, with proof¬ 
relevant equality, such a specification is wrong; it would fail to find an instance 
C (Maybe a) when we seek an instance for C (Maybe lnt> (Type)). Instead, we want 
9 and 7 such that S; T 1^ 0 7 : T\ [9] ~ t 2 [9] (for an appropriate E and P). Experience 
has shown that constructing the 7 is a real challenge . 98 

98 When I attempted this implementation, the coercion language was a bit different than presented 
in Pico. In particular, I did not have the « coercion form, instead having the much more restricted 
version of coherence that appears in my prior work [105]. The new form « is admissible given the 
older form, but it is not easy to derive. It is conceivable that, with si, this implementation task would 
now be easier. 
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7.2.1 Properties of a new definitional equality = 

The problem, as noted, is that the = relation is too small. How can we enlarge this 
relation? Since the relation we seek deviates both from a-equivalence and from ~, 
we need a new name: let’s call it =, as it will be the form of definitional equality in 
the implementation. (The relation is checked by the GHC function eqType , called 
whenever two types must be compared for equality.) We will define a new type system, 
PiCO=, based on =. Here are several properties we require of =, if we are to adapt 
the existing metatheory for PlCO: 

Property 7.1. The = relation must be an equivalence. That is, it must be reflexive, 
symmetric, and transitive. 

Property 7.2. The = relation must be a superset of =. That is, if Ti = t 2 , then 
Tl = t 2 . 

Property 7.3. The = relation must be a subset o/~. That is, if Ti = t 2; then there 
must be a proof of T\ ~ t 2 (in appropriate contexts). 

Property 7.4. The = relation must be congruent. That is, if corresponding components 
of two types are =, then so are the two types. 

Property 7.5. The = relation must be proof-irrelevant. That is, r = r \> 7 for all r. 

Property 7.6. The = relation must be homogeneous. That is, it can relate two types 
of the same kind only. 

Property 7.7. Computing whether T\ = t 2 must be quick. 

We need Properties 7.1-7.4 for soundness. I will argue below that we can transform 
the typing rules for PlCO to use = where they currently use =. This argument relies 
on these first four properties. 

Property 7.5 means that our new definition of = indeed simplifies the imple¬ 
mentation. After all, seeking a proof-irrelevant (that is, coherent) equality is what 
started this whole line of inquiry. However, despite Property 7.5 masquerading as 
only a desired property, it turns out that with my proof technique, this is a necessary 
property. Indeed, it seems that once = is any relation strictly larger than =, it must 
be proof irrelevant. This is because the translation from a derivation in PlCO= to one 
in PlCO (see next subsection) will use coercions as obtained through Property 7.3. 
These coercions must not interfere with =-equivalence. 

Property 7.6 arises from the use of = (that is, eqType ) in the implementation. 
There are many places where we compare two types for equality and, if they are equal, 
arbitrarily choose one or the other. Thus, = must be substitutive and accordingly 
homogeneous. 

Property 7.7 arises because we use eqType very frequently. A slow computation or 
a search simply is not feasible. 
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Beyond these requirements, a larger = relation is better. Having a larger = makes 
implementing PlCO easier, as we will be able to replace one type with another type, 
as long as the two are =. Thus, having more types be related makes the system more 
flexible. 

7.2.2 Replacing = with = 

We can take the typing rules of PlCO and mechanically replace uses of = (over types) 
with = to form the rules of PlCO=. This is done by looking for every duplicated use 
of a type in the premises of a rule, and putting in a = instead. 

For example, the application rule is transformed from 

E; T ht y Ti : na: Re |Kq. k 2 E; T b y t 2 : 

zz zr : . z _L Y APPxxEL 

E; T Hty Ti t 2 : k 2 [t 2 /a\ 


to 


E; T Iffy Ti : K 0 Kq = Ua: Re \Ki. k 2 

E; r I hty t 2 : Ki K\ = 


E; r Ihty TiT 2 : k 2 [t 2 /a\ 


DTy_AppRel 


This new rule allows K\ and k\ not to be a-equivalent, as long as they are . It 
also makes use of an extraction operator = that pulls out the component pieces of 
a type, respecting =-equivalence. The full set of rules that define PlCO= appear in 
Appendix F. 

Continuing the notational convention where J can stand for any of the judgments 
by, bo, bit, b<-op, btx, bee, or b, we have following lemmas, relating PlCO= to PlCO: 


Lemma (PlCO~ is an extension of Pico). If E; T b J then E; T lb J. 


Proof. Corollary of Property 7.2 of the definition of =. □ 

We also need a lemma where a result in PlCO= implies one in PlCO. This is harder 
to state, as it requires an operation that translates a term r that is well typed in PlCO= 
into one well typed in PlCO. We write the latter as |Y]. The translation operation [•] 
is actually a deterministic operation on the typing derivation in PlCO=; the conversion 
is valid only when the original type is well formed in PlCO=. The full statement of the 
lemma relating PlCO = to PlCO appears in Appendix F, but the following informal 
statement will serve us well here: 


Lemma (PlCO- is sound [Lemma F.10]). //E;T lb J, then E; [T] b \J^\- 

With both of these lemmas in hand, we can see that PlCO and PlCO= are equivalent 
systems and that all of the results from PlCO carry over to PlCO-. 
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7.2.3 Implementation of = 

Having laid out the properties we require of =, my choice of implementation of = is 
this: 

Definition (Definitional equality =). We have T\ = 72 whenever [ftij = [^ 2 ] and 
|_TiJ = \j 2 \, where Ti : K\ and t 2 ■ k 2 . 

The operation |_tJ here is the coercion erasure operation from Section 5.8.3. It 
simply removes all casts and coercions from a type. In the implementation, we can 
easily go from a type to its kind, as all type variables in GHC store their kinds directly 
(as also described in Section 6.9.4), with no need for a separate typing context. The 
implementation actually optimizes this equality check a bit, by comparing the kinds 
only when the type contains a cast—this avoids the extra check in the common case 
of a simple type. 

This equality check easily satisfies the properties described above. It also supports 
the extraction operation, which simply looks through casts. 

7.3 Unification 

It is often necessary to unify two types. This is done in rule Alt_ Match in PlCO 
but is also necessary in several places during type inference—for example, when 
matching up a class instance with a constraint that must be solved. With dependent 
types, however, how should such a unifier work? For example, should (a b ) unify with 
(tct) > 7 ? The top-level forms of these are different, and yet, intuitively, we would 
want them to unify. In other words, we want an algorithm that does unification up to 

I have thus implemented a novel unification algorithm in GHC that does indeed 
unify the forms above. To first order, this algorithm simply ignores casts and coercions. 
The problem if we ignore coercions altogether is that the resulting substitution might 
not be well kinded. As a simple example, consider unifying a with t > 7 . If we just 
ignore casts, then we get the substitution r/a —but t and a might have different kinds. 
In the type application example, we similarly do not want the substitution t/ a, cr/b 
but instead (t > 71 )/a, (cr > 7 2 )/b for appropriate 71 and 72 . 

My approach, then, is for the algorithm to take three inputs: the two types to 
unify and a coercion between their kinds. At the leaves (matching a variable against a 
type), we insert this coercion to make the substitution well kinded. At interior nodes, 
we simply ensure that we have a new kind coercion to pass to recursive calls. 

The unification algorithm is in Figure 7.1 on the next page. It works in the context 
of a UM monad that can handle failure and stores the ambient substitution produced 
by unification. I will highlight a few interesting points in this algorithm: 

• The unify function considers only those types which might be values. It specifically 
avoids treating case or fix. This is because non-values are flattened away before 
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unify :: Type —>• Type —>• Coercion —>• UM () 
un/ 7 y (ti > 7 ) t 2 77 = unify 77 t 2 (7 9 77) 

un//y t1 (t 2 > 7 ) 77 = unify t1 t 2 (77 9 sym 7 ) 

un//y a t 2 77 = unifyVar a t 2 77 

un//y t 1 a 77 = unifyVar a 77 (sym 77) 

unify H {Yl} H {Y2 } _ = unifyTys 77 t 2 

un/fy (ri cti) (t 2 ct 2 ) _ = unifyTyApp 77 07 t 2 <x 2 

un/fy (ti {07}) (t 2 {cr 2 }) _ = unifyTyApp 77 cti t 2 ct 2 

un/fy (ti ) (t 2 ) _ = unifyApp 77 t 2 

un/ 7 y (na: p 7Ci.Ti) (na: p yc 2 .T 2 ) = do un/ 7 y «7 rc 2 (Type) 
un/Ty n t 2 (Type) 

unify (Uc:fa.Ti) (IIc: 0 2 .t 2 ) _ = do unifyProp (f> 1 fa 

unify Ti t 2 (Type) 
un/ 7 y (Aa: p /ci.ri) (Aa: p K 2 .r 2 ) = do un/ 7 y «7 k 2 (Type) 

unify Ti t 2 (typeKind 77) 

unify (Ac:^i.Ti) (Xc:fa.T 2 ) _ = do unifyProp fa fa 

unify 77 r 2 (typeKind 77) 
unify _ _ _ = TDzero 

unifyVar :: TyVar —>• 7 ype —>• Coercion —>• UM () 
unifyVar a t 2 77 = do mti ■<— substTyVar a 
case mtl of 

Nothing —>• bindTv a (t 2 > sym 77) 

Just 77 —>• unify n r 2 77 
unifyTys :: [ 7 ype] —>■ [ 7 ype] —^ UM () 
unifyTys [] [] = return () 

unifyTys (77:77) (t 2 :t 2 ) = do unify 77 t 2 (typeKind 77) 
unifyTys 77 r-2 

unifyTys = 777 zero 

unifyTyApp :: Type —>• Type —>• 7 ype —>• Type —>• UM () 

unifyTyApp 77 07 t 2 ct 2 = do unifyApp 77 t 2 

un/'/y (71 cr 2 ( typeKind 07) 
unifyApp :: Type —>• 7 ype —>■ UM () 
unifyApp 77 t 2 do let «7 = typeKind 77 
k 2 = typeKind r 2 
unify «i k 2 (Type) 
unify 77 t 2 («i) 

unifyProp :: Prop —>■ Prop -7 UM () 

unifyProp (77 K1 ~ K i T () (t 2 K2 ~ k 2^) = unifyTys [k,. /*(. 77. 7 -[] [/c 2 , * 4 , t 2 , r^] 


Figure 7.1: A unification algorithm up to = 
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the unification algorithm runs, as described in my prior work Eisenberg et al. 
[32, Section 3.3]. 

• Examine unifyApp. After unifying the types’ kinds, it just passes a reflexive 
coercion when unifying the types themselves. This is correct because, by the 
time we are unifying the types, we know that the ambient substitution unifies 
the kinds. The coercion relating the types’ kinds is thus now reflexive. 

• In the case, the algorithm does not make a separate call to unify kinds. This 
is because the r are always well typed under a closed telescope. Since unifyTys 
works left-to-right, the kinds of any later arguments must be unified by the time 
those types are considered. 

I claim, but do not prove, that this unification algorithm satisfies the properties 
necessary for type safety. See Section C.3. For further discussion about the neces¬ 
sary properties of this algorithm, see Note [Specification of Unification] in 
compiler/types/Unify .hs in the GHC source code repository at https://github. 
com/ghc/ghc. 

7.4 Parsing a 

As described in Section 2.3.1, the kind of types in Haskell has long been denoted 
as *. This choice poses a parsing challenge in a language where types and kinds 
are intermixed. Types can include binary type operators (via the TypeOperators 
extension), and Haskellers have been using * as a binary infix operator on types for 
some time. (For example, in the standard library GHC.TypeLits.) The parsing problem 
is thus: is * an infix operator, or is it the kind of types? 

GHC 8 offers two solutions to this problem, both already fully implemented. Firstly, 
forward-looking code should use the new constant Type to classify types. That is, we 
have Int :: Type. So as not to conflict with existing uses of datatypes named Type, 
this new Type is not always available but must be imported, from the new standard 
module Data.Kind. Type is available whether or not TypelnType is specified. 

The other solution to this problem is to let the parsing of * depend on what * 
is in scope. This approach is to enable a smoother migration path for legacy code. 
Without TypelnType specified, * is available under its traditional meaning in code 
that is syntactically obviously a kind (for example, after a :: in a datatype declaration). 
When TypelnType is turned on, * is no longer available but must be imported from 
Data. Kind. This way, a module can choose to import Data.Kind’s * or a different *, 
depending on its needs. Of course, the module could import these symbols qualified 
and use a module prefix at occurrence sites to choose which * is meant. Because * is 
treated as an ordinary imported symbol under TypelnType, module authors can now 
use standard techniques for managing name conflicts and migration. 
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In order to implement this second solution, the parser treats a space-separated 
sequence of type tokens as just that, without further interpretation. Only later, when 
we have a symbol table available, can we figure out how to deal with *. This extra 
step of converting a sequence of tokens to a structured type expression outside of the 
parser actually dovetails with the existing step of fixity resolution, which similarly 
must happen only after a symbol table is available. 

7.5 Promoting base types 

This dissertation has dwelt a great deal on using algebraic datatypes in types and 
kinds. What about non-algebraic types, like Int , Double, or Char ? These can be used 
in types just as easily as other values. The problem is in reducing operations on these 
types. For example, if a type mentions 5 — 8, the normal type reduction process in 
the type-checker can replace this with (—3). However, what if we see 5 + x — x for an 
unknown x? We would surely like to be able to discover that (5 + x — x) ~ 5. Proving 
such equalities is difficult however. 

It is here that a new innovation in GHC will come in quite handy: type-checker 
plugins. Diatchki [22] has already used the plugin interface (also described by Gundry 
[38]) to integrate an SMT solver into GHC’s type-checker, in order to help with GHC’s 
existing support for some type-level arithmetic. As more capabilities are added to 
types, the need for a powerful solver to deal with arithmetic equalities will grow. 
By having a plugin architecture, it is possible that individual users can use solvers 
tailored to their needs, and it will be easy for the community to increase the power of 
type-level reasoning in a distributed way. These plugins can easily be distributed with 
application code and so are appropriate for use even in deployment. 
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Chapter 8 

Related and future work 


There is a great deal of work related to this dissertation, looking at designs of similar 
surface languages, designs of similar intermediate languages, and similar type inference 
algorithms. This chapter reviews this related work, starting with a thorough comparison 
with the work of Gundry [37], which covers all of the areas above. 


8.1 Comparison to Gundry’s thesis 

The most apt comparison of my work is to that of Gundry [37]. His dissertation is 
devoted to much the same goal as mine: adding dependent types to Haskell. I have 
tried to compare my work to his as this has been topical throughout this work. Here I 
summarize some of the key points of difference and explain how my work expands 
upon what he has done. 

8.1.1 Unsaturated functions in types 

Gundry’s intermediate language uses one element of the grammar to represent both 
terms and types. But he offers separate typing judgments, as controlled by his use 
of a phase modality. In Gundry’s type system, every typing judgment holds at one 
of three phases runtime, compile time, or shared (Gundry’s Section 6.2). Gundry 
describes an access policy (Gundry’s Section 6.2.1) whereby an expression well typed 
at the shared phase can also be used in either the runtime or compile-time phases. 
Gundry’s use of phases is not unlike my use of relevance, where an expression well 
typed at Gundry’s compile-time phase would be irrelevant in my formulation. 

The big difference between my treatment and Gundry’s is that I essentially combine 
the shared and runtime phases. That is, anything that is allowed at runtime is also 
allowed in types. Gundry prevents A-expressions and unsaturated functions from 
being used in types. These constructs can be typed only at the runtime phase, never 

"Actually, one of four, but both Gundry and I keep coercion typing so separate from other typing 
judgments that I am excluding it here. 
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the shared or compile-time phases. Because of this restriction around unsaturated 
functions, Gundry’s system must carefully track where unsaturated functions appear 
and prevent any expression containing one from being used in a type or a dependent 
context. 

I avoid Gundry’s restriction by tracking matchable functions separate from un- 
matchable ones (Sections 4.2.4 and 5.8.6.4). This innovation permits me to allow 
unsaturated functions while retaining the useful left and right coercions. As a part of 
this aspect of my work, I also lift the matchable/unmatchable distinction into surface 
Dependent Haskell, giving the user access to the ’n, and V quantifiers. 

8.1.2 Support for type families 

Both Gundry’s and my treatments favor A-abstractions and case expressions over type 
families. In my case, I would support type families via compilation into those more 
primitive forms. Gundry’s work, however, explicitly does not support type families 
(Gundry’s Section 6.7.4). This lack of support is revealed in two missing features: 

Matching on Type Through the way I have constructed my case expressions— 
specifically, treating Type as just another type constant—I allow pattern-matching 
on elements of Type. Gundry’s treatment requires a scrutinee to be a member of a 
closed algebraic datatype. 

Unsaturated matching Haskell type families can match on unsaturated uses of 
data and type constructors, something not supported in Gundry’s work but supported 
in Pico. 

8.1.3 Axioms 

Gundry’s evidence language includes support for axioms. While the notion of type-level 
axioms has been used in much prior work to represent type families, Gundry uses them 
to represent notions beyond those possible in type families, such as the commutativity 
of some primitive addition operation. In order to set up his consistency proof, he 
needs to establish that the axioms are good , as defined in Gundry’s Definition 6.4 of 
his Section 6.5.1. Gundry does not provide an algorithm for determining whether a 
set of axioms are good , however. 

PlCO, in contrast, has no built-in support for axioms. One could try adding axioms 
as global coercion variables available in every context, but that would interfere with 
the current consistency proof (Section 5.10) which severely limits the use of coercion 
variables. It is conceivable that adding axioms to PlCO is possible by establishing 
some condition, like Gundry’s good , that claims that the axioms do not interfere with 
consistency. This remains as future work, however. 
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8.1.4 Type erasure 

Gundry proves a type erasure property similar to mine. However, there is one key 
difference: my type erasure erases irrelevant abstractions (as does today’s implementa¬ 
tion of System FC in GHC), while Gundry’s does not. It is not clear, however, that 
this change is significant, in that it might easily be possible to tweak Gundry’s system 
to allow erasure of irrelevant abstractions, too. 

See also Section 5.10.5.4 and Section 6.10.3 for further comments comparing my 
work to Gundry’s. 

8.2 Comparison to Idris 

Of the available dependently typed language implementations, Idris is the most like 
Dependent Haskell. Idris was designed explicitly to answer the question “What if 
Haskell had full dependent types?” [9, Introduction] The Idris implementation is 
available 100 and is actively developed. So, how does Idris compare with Dependent 
Haskell? I review the main points of difference, below. 

8.2.1 Backward compatibility 

From a practical standpoint, the biggest difference between Dependent Haskell and 
Idris is that the former joins an already existing ecosystem of Haskell libraries and 
developers. Dependent Haskell is a conservative extension over existing implementations 
of Haskell, and all legacy programs will continue to work under Dependent Haskell. 
Although Idris is certainly Haskell-like (and has a foreign-function interface available 
to call Haskell code from Idris and vice versa) it is still not Haskell. 

Pushing on this idea a bit more, for a project to be started in Idris, the programmers 
must decide, at the outset, that they wish to use dependent types, as its type system is 
Idris’s most distinctive feature. With Dependent Haskell, on the other hand, developers 
can choose to take a part of a larger Haskell application and rewrite just that part 
with dependent types. This allows for gradual adoption, something that is much easier 
for the general public to swallow. 

8.2.2 Type erasure 

Dependent Haskell and Idris take different approaches to type erasure. Idris’s approach 
is explained by Tejiscak and Brady [90] as a whole-program analysis, seeking out places 
where an expression is needed and ensuring that all such expressions are available at 
runtime. Naturally, such an approach hinders separate compilation, which the authors 
admit is important future work (Tejiscak and Brady’s Section 8.1). 

100 http://www.idris-lang.org/ 
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By contrast, Dependent Haskell depends on user-written choices—specifically, 
whether to use n or V when writing a type. 

Which approach is better? It is hard to say at this point. The Idris approach has 
the advantage of automation. It may be hard for a user to know what expressions 
(especially those stored in datatypes) will be necessary at runtime. The choice between 
n and V may also motivate library-writers to duplicate their data structures providing 
both options. This is much like the fact that many current libraries provide both strict 
and lazy implementations of core data structures, as the better choice depends on a 
client’s usage. Perhaps the option for library-writers to provide multiple versions of a 
datatype is an advantage, however: in Idris, a datatype’s parameter may be marked 
as relevant even if it is used only once. In that case, the Idris programmer is perhaps 
better served by using one data structure (with the field irrelevant) in most places 
and the other data structure (with the field relevant) just where necessary. Time will 
tell whether the Dependent Haskell approach or the Idris approach is better. 

8.2.3 Type inference 

All Idris top-level definitions must be accompanied with type annotations. Even local 
definitions must have type annotations, sometimes requiring scoped type variables. 
One might say, then, that Idris does no type inference, only type checking. For this 
reason, studying the type inference properties of the language might be less compelling. 
Indeed, Brady claims [9, Section 6] that Idris “avoid[s] such difficulties since, in general, 
type inference is undecidable for full dependent types. Indeed, it is not clear that type 
inference is even desirable in many cases...” 

While I admit that considering a principal-types property is much less compelling 
when all bindings are annotated, I still believe that writing a type inference algorithm 
or specification is helpful. I am unaware of a description in the literature of Idris’s 
algorithm beyond Brady [9, Section 4], describing the elaboration of an Idris program 
in terms of the tactics that generate code in Idris’s intermediate language, TT. 
Accordingly, it is hard to predict when an Idris program will be accepted. I tested the 
following program against the latest version of Idris (0.12.1): 

ty.Bool —> Type 

ty x = case x of True =>• Integer ; False =>• Char 
f:(x:Bool ) —ttyx 

f x = case x of True =>- 5; False => ’x ’ 
g:(x:Bool) —>• ty x 
gx = the (ty x) 

(case x of True => 5; False => ’x’) 
h:(x:Bool ) —>■ ty x 

h x = the (case x of True =>• Integer ; False =>- Char ) 

(case x of True =>• 5; False =>- ’x’) 
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Idris’s the is its form of type annotation, with t/je:(a:Type) —>• a —>• a. Both f and 
g are accepted, while h is rejected. Note that the only difference between g and h is 
that the body of ty is expanded in h. Is this a bug or the correct behavior? It is hard 
to know. 

In contrast, Chapter 6 describes a bidirectional inference algorithm that details 
how to treat such expressions. (All of f, g, and h are accepted in Dependent Haskell 
and today’s approximation thereof using singletons.) 

Beyond just having a specification, Dependent Haskell also retains Damas-Milner 
let-generalization for top-level expressions (as implemented by the IDecl_Synthe- 
SIZE rule of Bake) . This means that simply typed functions and local declarations need 
not have type ascriptions. Indeed, in translating Idris’s Effects library to Dependent 
Haskell (Section 3.2.3), I was able to eliminate several type annotations, needed in 
Idris but redundant in Haskell. Having let-generalization also powers examples like 
inferring the schema from the use of a dependently typed database access library 
(Section 3.1.3), the equivalent of which would be impossible in Idris. 

8.2.4 Editor integration 

One arena where Idris is clearly out ahead is in its user interface. Indeed, despite 
the fact that Idris is considerably younger, GHC has been clamoring to catch up to 
Idris’s user interface for some time now. Its emacs integration means that users can 
interactively peruse error messages, expanding out the parts of interest and easily 
ignoring the unhelpful parts [17]. Dependent Haskell and GHC have much to learn 
from Idris in this respect; dependently typed programming in Haskell will demand 
improvement. 


8.3 Comparison to Cayenne 

Beyond Idris, there are many other languages one might want a comparison against. 
The most frequent comparison I have been asked for, however, is to compare against 
Cayenne [3], which I shall do here. 

Cayenne is a language introduced in 1998 by Augustsson essentially as a dependently 
typed variant of Haskell. Of particular interest, it shares Dependent Haskell’s cavalier 
attitude toward termination: Cayenne supports general recursion and all types are 
thus inhabited by T. Accordingly, Augustsson admits that Cayenne is not useful as a 
proof assistant. However, he also argues that this admission does not mean it is useless 
as a programming language. My argument in support of allowing general recursion in 
a dependently typed language (Section 4.4.5) broadly echoes Augustsson’s Section 5, 
claiming that a verification of partial correctness is better than no verification at all. 

Despite the similarities between my work here and Augustsson’s, there are a 
number of key differences: 
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8.3.1 Type erasure 

Augustsson’s approach to type erasure is much simpler than mine. Cayenne erases 
all expressions of type Type—that’s the full description of type erasure in Cayenne. 
This simplistic view has two shortcomings, however: 

Cayenne erases too much Because every expression of type Type is lost, Cayenne 
must restrict its pattern-match facility not to work over scrutinees of type Type. 
Dependent Haskell allows matching on Type. 

Cayenne erases too little Sometimes expressions of a type other than Type can be 
erased. For example, consider this function over length-indexed vectors (Section 
3.1.1): 

safeHead :: Vec a (’Succ n) —>■ a 
safeHead (x :> _) = x 

The n parameter to safeHead has type Nat and yet it can be erased in the call 
to safeHead. Cayenne would have no way of erasing this parameter. 

8.3.2 Coercion assumptions 

Cayenne has no support for equality assumptions. This means that it does not support 
GADTs (Section 2.4) or dependent pattern matching (Section 4.3.3). Lacking these 
features significantly simplifies the design of the language and implementation, meaning 
that many of the type inference issues (specifically, untouchability of type variables) 
described by Vytiniotis et al. [99] are avoided. The lack of equality assumptions also 
severely weakens Cayenne’s ability to support intrinsic proofs—that is, types whose 
structure ensure that all values of those types are valid (like Vec, which ensures 
that the vector is of the given length). Cayenne thus truly supports only extrinsic 
proofs: proofs written separately from the functions and data structures they reason 
about. These proofs must be written explicitly (intrinsic proofs are often encoded 
into the structure of a function) and offer more opportunity to accidentally use a 
non-terminating proof. 

8.3.3 A hierarchy of sorts 

Cayenne uses an infinite hierarchy of sorts, similar to many other dependently typed 
languages, but in contrast to Dependent Haskell, with its Type:Type axiom. Au- 
gustsson describes this design decision as working in support of Cayenne’s treatment 
as logical framework (if the user takes on the burden of termination checking) as well 
as to support Cayenne’s implementation of type erasure. 
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8.3.4 Metatheory 

While Augustsson presents typing rules for Cayenne, he offers no metatheory analysis 
for Cayenne beyond proving that the evaluation of a type-erased program simulates the 
evaluation of the original. Similarly, Augustsson does not describe any type inference 
properties in detail. The language requires top-level type annotations on all definitions, 
but inference is still necessary to check a dependently typed expression. Instead, 
Augustsson claims that “Type signatures can be omitted in many places” but does not 
elaborate [3, fourth-to-last bullet in Section 3.2], Cayenne does syntactically require 
all function arguments to be annotated, however. 

8.3.5 Modules 

Cayenne has a robust module system, more advanced than Haskell’s. As such, its 
module system is more advanced also than Dependent Haskell’s. Cayenne uses depen¬ 
dent records as its modules, as a dependent record can store types as easily as other 
expressions. It remains as future work to see whether or not Dependent Haskell can 
incorporate these ideas and use records as modules. 

8.3.6 Conclusion 

As an early attempt to bring dependent types to Haskell, Cayenne deserves much 
credit. Despite being declared dead in 2005 101 , Haskellers still discuss this language. It 
may have been the first thought-out vision of what a Haskell-like dependently typed 
language would look like and thus serves as an inspiration for both Agda and Idris. 


8.4 Comparison to Liquid Haskell 

Liquid Haskell [93-95] is an ongoing project seeking to add refinement types to Haskell. 
A refinement type specifies a head type and a condition; any value of the refinement 
type is asserted to meet the condition. For example, we might write the type of the 
length function thus: 

length:: [a] —>• {n:lnt \ n ^ 0} 

The return type tells us that the return value will always be non-negative. 

The Liquid Haskell implementation works by reading in such annotations with 
a Haskell file and checking that the refinements are satisfied. The check is done via 
an SMT solver. No user intervention—other than writing the refinements in the first 
place—is required. 

101 http://lambda-the-ultimate.org/node/802 
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Liquid Haskell and Dependent Haskell are, in some ways, two different solutions 
to (nearly) the same problem: the desire to rule out erroneous programs. By speci¬ 
fying tight refinements on our function types, we can have Liquid Haskell check the 
correctness of our programs. And doing so is easy, thanks to the power of the SMT 
solver working in the background. 

However, the refinement types of Liquid Haskell exist outside of the type system 
proper: it is not possible to write a type-level program that can manipulate refinements, 
and it is also not possible to write refinements that can reason about Haskell’s type 
classes or other advanced type-level features. Along similar lines, it is not possible to 
use refinement types to write a program inadmissible in regular Haskell; for example, 
refinement types are not powerful enough to encode something like Idris’s algebraic 
effects library (Section 3.2.3). 

The beauty of Liquid Haskell is in its user interface. Proving that a program matches 
its specification is fully automatic—something very much not true of Dependent Haskell 
programs. The project has shown without a doubt that using an SMT solver to help 
type-checking will lessen users’ proof burden. (Liquid Haskell is hardly the only tool 
that uses an SMT solver for type-checking. See also, for example, Leino [54] and 
Swamy et al. [89], among others.) 

It is my hope that, someday, Dependent Haskell can be the backend for Liquid 
Haskell. The merged language would have the type refinement syntax much like 
Liquid Haskell’s current syntax, but it would desugar to proper dependent types 
under the hood. An SMT solver would remain as part of the system, possibly as a 
type-checker plugin. For function arguments, supporting refinement types is already 
possible: a type like {mint \ n ^ 0} can be encoded as a dependent parameter n and 
a Haskell constraint. Much more problematic is a refined return type. For that same 
refinement, we would need a existential package, saying that a function returns some 
n with n ^ 0. While Dependent Haskell supports existentials, packing and unpacking 
these must be done manually. In practice, this packing and unpacking clutters the 
code considerably and makes the refinement approach distasteful. Perhaps worse, 
the packing and unpacking would be performed at runtime, making end users pay 
a cost for this compile-time checking. Overcoming these barriers—coming up with 
a lightweight syntax for existentials as well as zero runtime overhead—is important 
future work, perhaps my highest-priority new research direction. 


8.5 Comparison to Trellys 

The Trellys project [13, 14, 85] aims toward a similar goal to my work here: including 
dependent types in a language with non-termination. However, the Trellys approach 
is quite different from what I have done here, in that the language is formed of two 
fragments: a logical fragment and a programmatic fragment. The two halves share 
a syntax, but some constructs (such as general recursion) are allowed only in the 
programmatic fragment. Proofs in the logical fragment can be trusted (and never have 
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to be run) but can still mention definitions in the programmatic fragment in limited 
ways. 

Zombie [85], one of the languages of the Trellys project, allows potentially non¬ 
terminating functions in types but retains decidable type-checking by forcing the user 
to indicate how much to ^-reduce the types. This stands in contract to Dependent 
Haskell, where type-checking is undecidable. 

8.6 Invisibility in other languages 

Section 4.2.3 describes how Dependent Haskell deals with both visible and invisible 
function arguments. Here, I review how this feature is handled in several other 
dependently typed languages. 

Agda In Agda, an argument in single braces {...} is invisible and is instantiated 
via unification. An argument in double braces {{...}} is invisible and is instantiated 
by looking for an in-scope variable of the right type. One Agda encoding of, say, the 
Show class and its Show Bool instance would be to make Show a record containing 
a show held (much like GHC’s dictionary for Show ) and a top-level variable of type 
Show Bool. The lookup process for {{...}} arguments would then find this top-level 
variable. 

Thus, show's type in Agda might look like V { a} — > {{ Show a }} —> a — String. 

Idris Idris supports type classes in much the same way as Haskell. A constraint 
listed before a (=£>) is solved just like a Haskell type class is. However, other invis¬ 
ible arguments can also have custom solving tactics. An Idris argument in single 
braces {...} is solved via unification, just like in Agda. But a programmer may in¬ 
sert a proof script in the braces as well to trigger that proof script whenever the 
invisible parameter needs to be instantiated. For example, a type signature like 
func:{ default proof {trivial} pf:r} —>■ ... names a (possibly dependent) parameter 
pf, of type r. When func is called, Idris will run the trivial tactic to solve for a value of 
type r. This value will then be inserted in for pf. Because a default proof script of trivial 
is so common, Idris offers an abbreviation auto which means default proof {trivial}. 

Coq Coq has quite a different view of invisible arguments than do Dependent Haskell, 
Agda, and Idris. In all three of those languages, the visibility of an argument is part 
of a type. In Coq, top-level directives allow the programmer to change the visibility of 
arguments to already-defined functions. For example, if we have the definition 

Definition id A (x:A) :—x. 

(without having used Set Implicit Arguments) both the A and x parameters are 
visible. Thus the following line is accepted: 
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Definition mytrue 1 := id bool true. 


However, we can now change the visibility of the arguments to id with the directive 
Arguments id {A} x. 
allowing the following to be accepted: 

Definition mytrue 2 := id true. 

Although Coq does not allow the programmer to specify an instantiation technique 
for invisible arguments, it does allow the programmer to specify whether or not 
invisible arguments should be maximally inserted. A maximally inserted invisible 
argument is instantiated whenever possible; a non-maximally inserted argument is 
only instantiated when needed. For example, if the A argument to id were invisible and 
maximally inserted, then any use of id would immediately try to solve for A ; if this 
were not possible, Coq would report a type error. If A were not maximally inserted, 
than a use of id would simply have the type fora 11 A,A—>A, with no worry about 
invisible argument instantiation. 

The issue of maximal insertion in Dependent Haskell is solved via its bidirectional 
type system (Section 6.4). The subsumption relation effectively ensures that the correct 
number of invisible parameters are provided, depending on the context. 


8.7 Type erasure and relevance in other languages 

Pico’s approach to relevance and type erasure is distinctive and pervasive in its 
definition. Here I review several other approaches to type erasure in other languages 
and calculi. 

Gundry’s evidence language, Idris, and Cayenne See Sections 8.1.4, 8.2.2, 
and 8.3.1, respectively. 

Agda The Agda wiki contains a comprehensive page on Agda’s support for irrel¬ 
evance annotations. 102 The user can annotate certain definitions and parameters as 
irrelevant, by preceding them with a . prefix. Irrelevant values can be used in irrelevant 
contexts only, much like how PlCO treats irrelevantly bound variables. Irrelevant fields 
to a data constructor are ignored in an equality check, a feature that PlCO does not 
currently support. For example, consider the following Agda program: 

data T.Set where 
mkT: .(n:N) T 
data S:T —>• Set where 

102 http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Ref erenceManual.Irrelevance 
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mkS: ,(n:N) —* S (mkT n ) 
x:S (mkT 3) 
x = mkS 3 
y:S (mkT 4) 
y = x 

This program is accepted despite the fact that x and y have manifestly different types. 
Yet because the parameter to mkT is denoted as irrelevant, the types are considered 
equal. Note that, due to the restrictions around irrelevant contexts, if we remove the . 
prefix to the parameter to mkT, the constructor type for mkS would fail to type-check, 
because it uses its irrelevant argument n in a relevant context (as the argument to the 
now-relevant mkT constructor). Conversely, dropping the . in the type of mkS would 
not affect type checking. 

It would be interesting future work to see how using relevance in this way might 
affect Dependent Haskell. 

Despite having support for these irrelevance annotations, it seems that Agda does 
not have a well articulated type erasure property, instead depending on the extraction 
mechanism used to run Agda code. 

Coq Coq uses an altogether different approach to relevance and erasure. Coq has 
two primary sorts, Prop and Set. (I am ignoring the infinite hierarchy of Types that 
exist above Prop and Set.) All inhabitants of Prop are considered irrelevant and 
are erased during extraction. Coq thus enforces restrictions on the use of elements of 
types in Prop: chiefly, in the definition of an element of a type in Set, a program may 
not pattern-match on an element of a type in Prop unless that type has exactly 0 or 
1 constructors. In other words, the choice of a value of a type in Set may not depend 
on any information from a type in Prop. This is sensible, because that information 
will disappear during extraction. 

Because of Coq’s separation between Set and Prop, it is sometimes necessary 
to have duplicate data structures, some with Set types and some with Prop types. 
(For example, the Coq standard library has three different variants of an existential 
package— ex, sig and sigT — depending on which parts are in Prop vs. Set.) Such 
duplication might also appear in Dependent Haskell, as I argue in Section 8.2.2. 

ICC* Barras and Bernardo [7] introduce ICC* as a variant of Miquel’s Implicit 
Calculus of Constructions [64], ICC* contains two forms of n-type as well as two forms 
of A-extraction, in much the same way as PlCO. The ICC literature uses “implicit” 
and “explicit” to refer to the concepts I call “irrelevant” and “relevant”, respectively; I 
will continue to use my own terminology here. (Further muddying these waters, the 
original ICC also makes irrelevant arguments invisible. I have endeavored to keep 
visibility and relevance quite separate in this dissertation.) ICC* includes an erasure 
operation that converts ICC* expressions to ICC expressions by erasing irrelevant 
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arguments. In order to enforce appropriate use of irrelevant arguments, irrelevantly 
bound variables are forbidden from appearing in the erased, ICC-form of the body of 
an abstraction. This restriction is enforced by a simple check for free variables in the 
typing rule of the irrelevant A-abstraction, in contrast to Pico’s approach of tracking 
relevance in contexts. The PlCO equivalent to ICC*’s approach would resemble this 
rule: 

E;T, a:aky t : k a $ fvQrJJ) 

- t i, —:-—- 1 y Lam 

E; r by Aa:| rre |CT. r : Ua: inei a. k 

It is possible that such a rule would simplify the statement of PlCO, but I imagine it 
would complicate the proofs—especially of type erasure—as there would have to be a 
way of propagating the information about where irrelevant variables can appear. 

8.8 Future directions 

With the design for Dependent Haskell laid out here, what work is left to do? First and 
foremost, I must tackle the remainder of the implementation as sketched in Section 
7.1.3. However, beyond that, there are many more research questions left unanswered: 

• With the added complexity of dependent types, type error messages will surely 
become even harder to read and act on. How can these be improved? Idris’s 
technique of displaying interactive error messages (Section 8.2.4) may be a step 
in the right direction, but it would be even better to have some theory of error 
messages to use as a guiding principle in solving this problem. 

• Relatedly, dependent types work wonders for authors who wish to write an 
embedded domain-specific language. Programs might be written in such an 
EDSL by practitioners who do not know much type theory or Haskell. How can 
we expose a way for the DSL writer to customize the type error messages? 

• What editor support is necessary to make dependent types in Haskell practical? 
Leading dependently typed languages (specifically, Coq, Agda, and Idris) all have 
quite advanced editor integration in order to make development more interactive. 
Haskell has some integration, but likely not enough to make dependently typed 
programming comfortable. What is missing here? 

• Some dependently typed languages have found tactics a useful way of constructing 
proofs. Would such a technique be feasible in Dependent Haskell? What would 
such a facility look like? 

• One of GHC’s chief strengths is its optimizer. Once we have dependent types, can 
type-level information inform optimization in any meaningful way? In particular, 
using dependent types, an author might be able to write down “proofs” that a 
Monad instance is lawful. Can the optimizer take advantage of these proofs? 
Will we have to trust that they terminate to do so? 
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• How will dependent types interact with type-checker plugins? How can we use 
an SMT solver to make working with dependent types easier? 

• Dependent types will allow for proper dependent pairs (E-types). Is it worth 
introducing new syntax to support these useful constructs directly? Would this 
new syntax also pave the way for better integration with Liquid Haskell (Section 
8.4)? 

• This dissertation has proved that the output of the Bake algorithm is a type- 
correct PlCO program. It has not rigorously established, however, a principal 
types property or conservativity over today’s Haskell. What steps are missing 
before we can prove these? 

• One might reasonably ask whether all the fancy type-level bells and whistles 
affect parametricity. I do not believe they do, but it would be informative to try 
to prove this directly. 


8.9 Conclusion 

This chapter has really only scraped the surface of related work. There are simply 
too many dependently typed languages and calculi available to compare against all of 
them. In this crowd, however, Dependent Haskell stands out chiefly for its unapologetic 
embrace of non-termination and partial correctness. Dependent Haskell is, first and 
foremost, a programming language, and many valuable programs are indeed non¬ 
terminating or hard to prove to be total. These programs are welcome as first-class 
citizens in Dependent Haskell. 
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Appendix A 

Typographical conventions 


This dissertation is typeset using E'TfrX with considerable help from lhs2TeX 103 and 
ott [82], The lhs2TeX software allows Haskell code to be rendered more stylistically 
than a simple verbatim environment would allow. The table below maps Haskell 
source to glyphs appearing in this dissertation: 


Haskell 

Typeset 

Description 

-> 

—>• 

function arrow and other arrows 

=> 


constraint arrow 

* 

* 

the kind of types 

forall 

V 

dependent irrelevant quantifier 

Pi 

n 

dependent relevant quantifier 

++ 

% 

list concatenation 



heterogeneous propositional equality 

: ~> 


lambda-calculus arrow (from Section 3.1.2) 

undefined 

JL 

canonical looping term 


Figure A.l: Typesetting of Haskell constructs 

In addition to the special formatting above, I assume a liberal overloading of number 
literals, including in types. For example, I write 2 where I really mean Succ (Succ Zero), 
depending on the context. 


103 http://www.andres-loeh.de/lhs2tex/ 
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Appendix B 

PICO typing rules, in full 


B.l Type constants 


E^ c H : Ai;A 2 ;tf' 


Type constant kinds, with universals A 1; 
existentials A 2 , and result H' 

———-—- Tc Type 

E hf c Type : 0; 0; Type 

T:(a:K) £ E 

^ V _ _ ^ - Tc ADT 

E hf c T : 0; a:R e |fi;; Type 

A:(A; T) G E T:(a:«) E E 

-————— - — - Tc_DataCon 

E hfc K : a:| rre |K; A; T 


B.2 Types 


E; T hty t : k | 


Type formation 


E ^ tx T Ok CUReA C r 
E; T a : n 


Ty_Var 


E ht c A : A i; A 2 ; H' E T ok 
E; Rel(T) £ ec r : Rel(A^ 

E; T hy %} : , n(A 2 [r/dom(A 1 )]). H't 


E; T hty T\ : no: Re |/Ci. k 2 E; r ht y t 2 : 
E; T hf y t i t 2 : k 2 [t 2 /a] 


Ty_AppRel 
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E; T ht y Ti : IIa:i rre |/ci. n 2 E; Rel(r) ht y r 2 : 
E; T hfy Ti{t 2 } : k 2 [t 2 Ja] 


Ty_AppIrrel 


E; r ^y t : ILc:<f>. k E; Rel(r) 7 : </> 
E;T hf y T7 : k[j/c] 


Ty_CApp 


E; T, Rel(5) l* k : Type 
E; T 115. k : Type 


E; Rel(r) 7 : ~ k 2 

E; T hfy r : E; Rel(r) h^ k 2 : Type 

E; T ht y t > 7 : k 2 


Ty_Cast 


E; Rel(r) h^ k : Type E; F hf y r : a 
a = TIA .Ha E; Rel(T) ky Ha: Type 
Vi, E; T; a ff !t alti : k 

alt are exhaustive and distinct for H , (w.r.t. E) 
E; T hfy case* r of alt : k 


Ty_Case 


E; T, 5 ht y t : k 
E; T ^ A 6. r : US. k 

E; T hfy t : IIfl: Re |K. k 


E; T hfy fixr : n 


Ty_Lam 


Ty_Fix 


E; Rel(r) 7 : H 1{Tl} ^ - H 2{Y2} ^ H 1 ± H 2 
E; Rel(r) hfy t : Type 

E; r h^ absurd 7 t : r 
S;r;a^ lt alt : /c | Case alternatives 

E ht c H : A i; A 2 ; H' A 3 , A 4 = A 2 [o : /dom(A 1 )] 
dom(A 4 ) = dom(A') 

match{ dom( A 3 )} (types( A 4 ); types( A')) = Just# 

E; T ht y t : HA 3 , c:t 0 ~ H dom(A 3 ). k 
E: T: TIA'. H'a\^ t H -f t : k 


Ty_Absurd 


Alt _ Match 
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E; T hfy r : k 
E; T; <7 _ -M- : k 


Alt _ Default 


B.3 Coercions 


| E; r h^p 7 : 0 | Coercion formation 

e tax r ok c:cj) e r 
E; r ta c : </> 


E;T ta t : n 
S; T ta 

E; T ta 7 : Ti ~ t 2 
E; T ta sym7 : t 2 ~ t% 


E; T ta 7i : ta ~ t 2 


E; r ta 72 : t 2 - 


E; T ta 7 i 9 72 : ta ~ r 3 


Co _ Trans 


E; T ta V '■ ta * 
E; r ta T\ : K\ 


LnJ = ,N 
E; r ta t 2 : n 2 


E; T ta ta t 2 : Ti r 


Co Coherence 


Mi, E; T ta li ■ ta 
E; T ta 


E; T ta : ta 


E;T ta %>:%}• 


'Hi 


{*'} 


Co_Con 


E; r ta %»n ~ t 2 
E; r ta 72 : (Ti ~ ta 

E; r ta ta ta : Ni E; r hf y ta ta : n 2 

S; r ta 7i 72 : ta ta ~ ta <r 2 


Co AppRel 


E; T ta 7i : ta ~ ta 
E; r ta 72 : ta ~ ta 

S; T ta ta {ta} : ta S; T ta ta {ta} : ta 

E; T ta 7 i { 72 } : ta {ta} ~ ta {ta} 


Co_AppIrrel 





E; r bo 7o : Ti ~ t 2 

E; T tiy T\ 71 : Ki E; T by t 2 7 2 : k 2 
S; r bo 7o (71,72) : Ti 71 ~ t 2 7 2 


Co_CApp 


E; r bo TJ: m T yp e ~ T yp e k 2 

_ E; r, QiRei^i t^o 7 : tTi T yP e ~ T yP e g 2 _ 

E; r bo Ua-.pTj.'y : ( Ua: p Ki.ai ) ~ (II a: p n 2 . ( a 2 [a > sym rj/a])) 


Co_PiTy 


E; r 771 : Ti ~ t 2 E; T bo rj 2 : cri ~ a 2 

E; r, cm ~ at bo 7 : T yp e ~ T yp e c # 7 

V3 = Vi 9 C 5 sym 772 

E; T bo lie:(771, 77 2 ). 7 : (IIc:ti ~ 07. «i) ~ (IIc:t 2 ~ a 2 . (« 2 [?fe/ c])) 


Co_PiCo 


E; r bo 7o : Pi ' 


E; T bo 77 : Ki ~ h 
Vz, E; r tEo 7; : o’* ~ cr' 
alt 1 — 7Tt -A 07 alt 2 = 717 

E; T hfy case K1 Ti of alti : «7 


E; T ht y case K2 r 2 of alt 2 : k 2 


E; T bo case,, 70 of 77 


► 7i 


: case Kl 77 of alt\ ~ case K2 r 2 of alt 2 


E; T bo V : K\ ~ k 2 
E; T, a: p «7 bo 7 : Pi ~ p 
E; T, a\ p Ki by Pi : 07 
E; T bo Xa: p ri. 7 : \a: p K\. 77 ' 


E; T, a: p «i by P2 : 02 
\a: p K 2 . ( r 2 [a > sym 77/a]) 


E; r bo 771 : Pi ~ P2 E; r bo 772 : 07 ~ a 2 
E; T, c:ti ~ 07 b 0 7 : «7 ~ k 2 c # 7 

_ Vs = V19 c ; sym 772 _ 

E;T bo Ac:(t 7 i, 77 2 ).7 : (Ac:n ~ 07. «i) ~ (Ac:t 2 ~ a 2 . (k 2^3/c])) 


Co_CLam 


E; T bo 7 : Pi ~ P 2 

E; T by fix Ti : Ki E; T by fix r 2 : k 2 
E; T bo fix 7 : fix 77 ~ fix r 2 


Co_FlX 


E; r bo 7i : #i{n} V>1 ~ fi #i 7^ H{ 

51) r bo 72 : ^2{fa} V^2 ~ -^2{f 2 } ^2 -^2 7“ 

E; r bo 7? : ~ «2 

E; r bo absurd (71,72) 77 : absurd 7t ^7 ~ absurd 72 k 2 


Co_Absurd 
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E; T h^o 7 : (Ua: p Ki. < 7 \) ~ (Ua: p K 2 . <J 2 ) 
E; r h^ 0 argk7 : K\ ~ k 2 


Co_ArgK 


E; T 7 : (nc:(Ti ~ t{).0i) ~ (II c:(r 2 ~ t^).q- 2 ) 
E; T l^ 0 argk x 7 : 77 ~ r 2 


Co_CArgK1 


E; T 7 : (nc:(Ti ~ tQ.Oi) ~ (nc:(T 2 ~ r' 2 ).a 2 ) 
E; T l^o argk 2 7 : r{ ~ r 2 


Co_CArgK2 


E; T 7 : (Aa: p Ri. <7i) ~ (A a: p K 2 . a 2 ) 
E; r f^o argk7 : K\ ~ k 2 


Co_ArgKLam 


E; T h^p 7 : (Ac:(ti ~ tQ.oi) ~ (Ac:(t 2 ~ r ' 2 ). a 2 ) 
E; T \~ co argk : 7 : n ~ r 2 


Co_CArgKLam1 


E; T 7 : (Ac:(ti ~ tQ.Oi) ~ (Ac:(t 2 ~ t').(t 2 ) 
E; T h^o argk 2 7 : ~ t 2 


Co_CArgKLam2 


E; T h^ 0 7 : HAi. r% ~ HA 2 . t 2 | Ai| = | A 2 | = n 
E; T hty Ti : Type E; T t 2 : Type 
E; T h^ 0 res n 7 : 77 ~ t 2 


Co _ Res 


E; T h^o 7 : AAi. ti ~ AA 2 . t 2 |Ai| = |A 2 | = n 
E; T hty Ti : E; T t 2 : r 2 

E; T h ^ 0 res n 7 : ti ~ t 2 


Co_ResLam 


E; T h^ 0 7 : na: Re |/Ci. cri ~ na: Re |R 2 . cr 2 
E; T h^o 77 : Ti K1 ~* 2 T2 
E; T 7@?7 : cti[ti/ a] ~ cr 2 [r 2 /a] 


Co_InstRel 


E; r h^o 7 : na:i rre |/Ci. cri ~ na:| rre |R 2 . cr 2 
E; T h^o 77 : Ti K1 ~ K2 T2 
E; T 7@{t7} : a^/a] ~ cr 2 [T 2 /a] 


Co_InstIrrel 
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E; T h^o 771 : IIc: 0 i. cr x ~ nc: 0 2 . <72 
E; T 7l : E; T 72 : 0 2 

E; T h^o 77 i@( 7 i, 72 ) : <7i[ 7 i/c] ~ (7 2 [ 72 /c] 


CO_ClNST 


E; T 7 : Aa: Re iRi. Ti ~ Aa: Re ift 2 . t 2 
E;T 77 : a x Kl ~ K2 a 2 
E;r 7@?7 : ri[cri/a] ~ r 2 [a 2 /a] 


Co_InstLamRel 


E; T h^o 7 : Aa:i rre i/«i. n ~ Aa:i rre iR 2 . r 2 
E ; r^ 0 ?7 : 01 cr 2 

E; T 7@{r7} : Ti[<7i/a] ~ T 2 [cr 2 /a] 


Co_InstLamIrrel 


E; T 7 : Ac:0i. <Ji ~ Ac:0 2 . cr 2 
E; r 771 : 0i E; r 772 : 02 
E; T 7 @(t 7 i, 772) : ^[771/c] ~ cr 2 [772/c] 


Co_CInstLam 


E; T 7 : % } 0 ~ 0' 

0j = T 0' = <7 

E; T hty r : kr E; T a : n 2 
E; T h^o nth* 7 : t ~ cr 


Co_NthRel 


E; r 7 : fr {B} 0 ~ i? K} 0' 

0i = M 0- = {(7> 

E; Rel(r) t : «i E; Rel(r) hf y cr : k 2 
E; T h^o nthj 7 : t ~ cr 


Co_NthIrrel 


E; T 7 : Ti_0i ~ t 2 _ 0 2 

E; T ht y 77 : TWi. /Ci E; T hf y t 2 : TW 2 . r 2 

E; r 77 : TOi./d ~ TW 2 .«2 

E; T h^ 0 left,, 7 : t x ~ t 2 


Co_Left 


E; T h^o 7 : T\_u 1 ~ T 2 _cr 2 

E; T h^, (Ti : k x E; T ht y cr 2 : k 2 E; T bj 0 77 : k x ~ n 2 

E; T right^ 7 : 07 ~ <r 2 


Co_RightRel 
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Co_RightIrrel 


E; T 7 : Ti_{cti} ~ r 2 _{a 2 } 

E; T hf y (7i : Ki E; F hf y <r 2 : k 2 E; F h^, rj : Ki ~ n 2 
E; T h^o right^ 7 : cu ~ a 2 


E; T h^o 7 : ri K1 ~ K2 r 2 
E; r hj 0 kind 7 : K\ ~ k 2 


Co_Kind 


E; T h^ rop cj) ok 


E; T ht y t : k E; T h^ t' : k 
E; T I* r — >t' 

E; T h^, stepr : r ~ r' 
Proposition formation 


Co_Step 


E; T hty Ti : Ki 
Sj r hty r 2 : k 2 
E; r hj 3 rop Ti T2 ok 


Prop _ Equality 


B.4 Vectors 

I E; T h^ ec 0 : A Type vector formation 


E h^ tx r ok 
E; T h^ec 0 : 0 


VEC_NlL 


E; T hfy t : k 
E-F kec^- A[t/o] 

E; T h^ec T, 0 : a:R e \K, A 


Vec_TyRel 


E; Rel(r)Jty r : k 
E; T h^ec "0 : A[t/o] 

E; T h^ec {t}, V’ : a ; lrrel«, A 


Vec_TyIrrel 


E; r h^ev -0 : A 


S; Rel(r) h^o 7 : 0 
E;T kec^ : A[ 7 /c] 
E; T h^gc 7 ,0 : c:0, A 


Vec_Co 


Vector formation, reversed 
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E ktx r ok 
E; r h^gv 0 : 0 


Cev_Nil 


E; r ^ev -0 : A 

E; T hty t : «#/dom(A)] 
E; T h^ ev 0, r : A, a: Re |K 

E; T bev 0 : A 

E; Rel(r) by r : /#/dom(Aj] 
E; T bev -0, t : A, a:| rre |K 

E; T ^ ev 0 : A 


Cev_TyRel 


Cev_TyIrrel 


E; Rel(r) bo 7 : 0[0/dom(A)] 
E; T bev 0 ,7 : A, c:0 


Cev_Co 


B.5 Contexts 


big ^ ok Signature formation 


Sig_Nil 


big 0 ok 

s ^tx a:irrei^ok r# E 

big E, T:(a:K) ok 

T:(o,:k) e E E btx a:irrei^, A ok K # E 
big E, K:(A] T) ok 


Sig DataCon 


| E l-^ tx r ok | Context formation 

big E ok 


E; Rel(r) b y k : Type a # T 
E btx r, a\ p K ok 


Ctx TyVar 
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E; Rel (r) b prop 0 ok c # F E ^ tx T ok 
E h^x T, c:cj) ok 


Ctx CoVar 


B.6 Small-step operational semantics 

| E; r hj a —y a' Small-step operational semantics 

S_BetaRel 


S BetaIrrel 


S_CBeta 


E; T hi (Aa: Re | ac. —» ai[a 2 /a] 

E; T ii (Aa:i rre |R. Vi)_{a 2 } —> vy [a 2 / a] 

E; T I* (A c:(j). a)jy —► v\ljc\ 

alti = H — y To g 

E;T fi c&se K H{ Y y i/iof alt —> r 0 1 ; (//{ T > v) ~ 

alti = _ —>• a no alternative in alt matches H 

E; T !j case K H | T j if) of alt — y a 

alti = _ —3 y a no alternative in alt matches H 

E; T case K H^} 4> > 7 of alt —>• cr 

T = AaiRelR. cr 


S DefaultCo 


E;T I5 fixr — y affix r/a] 

E; T ii (v > 71) > 72 — y v > (71 ? 72) 
E; T, a:| rre |AC a —)■ a' 


S_ Unroll 


E; V li Aa:| rre |R. a —y Xa: inei K. a' 
E;T ^a — 


S_IrrelAbs_Cong 


E; T I5 a ip —y a' 


S App Cong 
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E;T hrcx — >a' 

E; T fi a > 7 —* a' > 7 


S_Cast_Cong 


E;T fjo- — >a' 

E; T ^ case T a of alt —> case T a 1 of alt 


S_Case_Cong 


E;T \- s t 
E; Hilixr 


S_Fix_Cong 


E; Rel(r) l^ 0 70 : IIa: Re |R. a ~ na: Re |K'. a ' 

71 = sym(argk7o) 72 = 7 0 @(t > 71 ft * sym71 r) 

E; T 1 ^ (v > 70) t —> v (t > 71) > 72 


S_PushRel 


E; Rel(r) 70 : na:| rre |R. a ~ na:i rr eiR'. a' 

71 = sym(argk7o) 72 = 7 0 @(t > 71 ft* sym71 

E; T fi (v > 70) {t} —» v {r > 71} > 72 




S_PushIrrel 


E; Rel(r) h^o 70 : Uc:(f>. a ~ II c:cj)'. a' 

7! = argk 1 7o 72 = argk 2 7 0 
rf = 7 i 9 V 9 sym 72 73 = 7 o@(*/, v) 

E; T fi (7; > 70) 77 —> f 77' > 73 


7l = na:| rre |(7c). 7 72 = Ti ~(Type) t 2 

77 = na:| rre |R. (/ci[a > sym (/c)/a]) t 2 = IIa:| rre |R. 

E; T f* Aa:i rre i«;. (u > 7) —> (Aa:i rre |R. v ) > (71 1 72) 


S_APush 


71 = 7 o@(a ~ 72 a > 72) 9 sym72 

_ 72 - argk 7 q _ 

E; T fi fix ((Aa: Re ,K. a) > 70) —> (fix (Aa: Re |R. (<r > 71))) > 72 


S_FPush 
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E ht c H : a:\ rre \K] A; H' A = A 1 ; A 2 n = |A 2 | 
k = Tla:\ rre \K, A. H'a 
a = TI(A 2 [r/a][VVdom(Ai)]). H't 
a' = , U(A 2 [t i / a][i^'H' t 1 
E; Rel(r) bo 77 : a ~ a' 

E; Rel(r) bee r' : a: Re |7t 

Vi, 7i = build_kpush_co((ft)@(nths (res" 77)); ^ 

Vi, 0' = cast_kpush_arg('0j; 7 j) 

H —>■ V E alt 

E; T b case Ko ( H {^> 0) > 77 of alt —> case Ko H^'} 0 of alt 


B.7 Consistency 


7~i oc t 2 Type compatibility 


T] is not a value 
n oc t 2 


C_ Non Value 1 


t 2 is not a value 
n oc t 2 


C_NonValue2 


- = -=7 C_TyCon 

Rjj} 0 OC 0 


rocr' 

IlaipTC. t oc IIa: p /V. r' 


IIc:0. t oc nc:0'. r' 


C_PiTy 

C_PlCo 


—-—- C_Lam 

Xd. t oc Ad)', r 

| t t' I Parallel reduction over erased types 

- R Refl 


S_KPush 
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R_Con 


T T <7 a 

r a t' a' 


T T <7 <7 

T {<7> T'{<7'} 


R AppIrrel 


S ^ S' t t' 


* a' 


case K r of f! PP if case K / r' of 7r —> a 1 

S ^ S' t t' 


XS. r ^ XS'. r' 


absurd • r 

absurd • t' 

Ti T{ 

t 2 -w 

(Aa: Re |R.Ti)_T2 

' w T \[ T U a \ 

Ti 

t 2 -w t ' 2 


(Aa:i rr eiR.Ti)_{T 2 } r^/a] 


R BetaRel 


R BetaIrrel 


(A t)j> t' 


R_CBeta 
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alti = H ^ tq tq Tq 

~ ^ ! x\ iVl Al 

case K Hs^j} V’ of alt Tq i/j • 

alti — _ —>• cr no alternative in alt matches H a ^ a 1 

case K i)j of alt cr' 


fix (AaiReift. cr) cr'[fix (Aa:R e |/d. cr')/a] 
> <5' Parallel reduction of binders 


R TyBinder 


r 2 R 2 cr -w cr 


R CoBinder 


“Reduction” of erased coercion 


R ErasedCo 


B.8 Small-step operational semantics of erased ex¬ 
pressions 


Single-step operational semantics of expressions 


(Aa.ei) e 2 —» ei[e 2 /a] 


ealti = H —>• e 


case H y of ealt —> e y • 


ealt t = _ —>• e no alternative in ealt matches H 

case H y of ea/t —> e 
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fix(Aa.e) —* e[fix(A a.e)/a\ 


case e of ealt —> case e' of ealt 


E_ Unroll 


Cong 


E_Case_Cong 


Cong 
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Appendix C 

Proofs about PICO 


You may find the full grammar for PlCO in Figure 5.1 on page 76 and its notation 
conventions in Figure 5.2 on page 77. The definition for values is in Section 5.7.1 and 
of the ff operator in Section 5.8.5.2. 


C.l Auxiliary definitions 

Definition C.l (Free variables). Define fv to be a function extracting free variables, 
overloaded to work over types r, coercions 7. propositions f>, vectors if, alternatives 
alt, and telescopes A. The definitions are entirely standard. 

Definition C.2 (Context extension). Define the relation F C T' to mean that F is a 
(not necessarily contiguous) subsequence ofF'. 

C.2 Structural properties 

C.2.1 Relevant contexts 

Lemma C.3 (dom/Rel). dom(Rel(r)) = dom(r) 

Proof. By its definition Rel(r) binds the same variables as F. □ 

Lemma C.4 (Subsequence/Rel). IfF CT' then Rel(T) C Rel(r'). 

Proof. By the definitions of C and Rel. □ 

Lemma C.5 (Rel is idempotent). Rel(Rel(r)) = Rel(r) 

Proof. By the definition of Rel. □ 

Lemma C.6 (Increasing relevance). Let F and T' be the same except that some 
bindings in T' are labeled Rel where those same bindings in F are labeled Irrel. 
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1 . If E; T hfy t : k, then E; T' by r : k. 

2 . If E; T bo 7 : 0, then E; F' bo 7 : 0 . 

3 . If E; T brop 0 ok, then E; T' brop 0 ok. 

4 . If E; F; cr 0 b°t alt : k, then E; T'; cr 0 b° t alt : k. 

5 . If E; T bee -0 : A ? then E; F' bee 0 : A. 

6. If E btx r ok 7 then E btx r' ok. 

7. If E; T b t —> t' , then E; T' b t —> r' . 

Proof By straightforward mutual induction, appealing to Lemma C.5. □ 

C.2.2 Regularity, Part I 

Lemma C.7 (Type variable kinds). If E btx T ok and a: p n e T, then there exists T' 
such that r' C Rel(r) and E; T' by k : Type. Furthermore, the size of the derivation 
of E; r' by ft : Type is smaller than that of E btx T ok. 

Proof. Straightforward induction on E btx T ok. □ 

Lemma C.8 (Coercion variable kinds). If E btx r ok and c:<j) e T, then there exists 
r' such that r' C Rel(r) and E; T' brop 0 ok. Furthermore, the size of the derivation 
of E; r' brop 0 I s smaller than that of E btx T ok. 

Proof. Straightforward induction on E btx T ok. □ 

Lemma C.9 (Context regularity). If: 

1 . E; T by r : k, OR 

2 . E; T bo 7 : <t>, OR 

3 . E; r brop 0 OR 

4. E; F: a Q tf| alt : k, OR 

5 . E; T bee 0 : A, OR 

6. E btx r ok 

Then E btx prefix(r) ok and big E ok, where prefix(r) is an arbitrary prefix of T. 
Furthermore, both resulting derivations are no larger than the input derivations. 

Proof. Straightforward mutual induction. □ 
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C.2.3 Weakening 

Lemma C.10 (Weakening). Assume E btx F' ok and T C r'. 

1. If E; T ht y t : k then E; T' by r : k. 

2. If E; T bo 7 : /, then E; F' bo 7 : 0. 

3 . If E; T h^ rop f> ok, then E; T' h^ rop / ok. 

4 . If E; T; cr 0 bit alt : k, then E; T'; cr 0 b° t alt : n. 

5. If E; Tkecf’- A, then E; T bee : A. 

6. If E btx T, A ok, then E btx r', A ok. 

7. If E; T b r —> r', then EjF^r —» t'. 

Proof. By straightforward mutual induction, appealing to Lemma C.4, Lemma C .6 
(in order to be able to use the induction hypothesis in, e.g., Ty_AppIrrel), and 
Lemma C.9 (in order to use the induction hypothesis in, e.g., Ty_Pi). □ 

Lemma C.ll (Strengthening). Assume T' C T and the variables 
(dom(r)} \{dom(r / )} are never used. 

1. If E; T by t : k then E; F' by r : k. 

2. If E; T bo 7 : <t>, then E; F' bo 1 ■ <t>- 

3 . If E; T brop / ok, then E; Y' b rop / ok. 

4- If E; Y; a 0 b°t alt : k, then E; T'; cr 0 b° t : K - 

5. If E; T bee ■ A, then E; I v bee ■ A. 

6. If E btx r ok, then E btx 1 v ok. 

7. If E; T b t —> t', then E; T' b t —» t'. 

Proof. Similar to previous proof. □ 

C.2.4 Scoping 
Lemma C.12 (Scoping). 

/. If E; T by t : k, then fv(r) C (dom(r)} and fv(/c) C (dom(r)}. 

2. If E; T bo 7 : /, then fv(y) C {dom(r)} and fv(/) C (dom(r)}. 

3 . If E; T brop / ok, then fv(/) C (dom(r)}. 

4- If S; T; cr 0 # —>■ r : k, then fv(r) C {dom(r)}. 

5. //EjT bee V’ : A, f/ien fv(-0) C (dom(r)} and fv(A) C (dom(r)}. 
d. If E btx r ok, t/ien fv(r) = 0. 

7. //big S ok and E be H : Ai; A 2 ; H', then fv(At) = 0 and fv(A 2 ) C {dom(A!)}. 
Proof. By straightforward mutual induction, appealing to Lemma C.3, Lemma C.7, 
Lemma C. 8 , and Lemma C.9. □ 
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C.3 Unification 

We assume the following properties of our unification algorithm. 

Property C.13 (Domain of match). If matchv(ri; r 2 ) = Just#, then 6 — if/~z for 
some and ~z with V — {z}. In other words, the domain of the substitution returned 
by a successful use of match is the variables V passed into match. 

Property C.14 (match is sound). If matchy(Ti; t 2 ) = Just#, thenri[6] = r 2 . 

Property C.15 (match/substitution). If matchy(ri; r 2 ) = Just# and dom(# 0 )nV = 
0 , match v (Ti[#o];T 2 [#o]) = Just 9 ' for some 9 '. 

C.4 Determinacy 

Lemma C.16 (Uniqueness of signatures). Assume big E ok. 

1. If T:(a:Ki) G E and T:(a:K 2 ) G E, then Ki = ~K 2 . 

2 . If K:(Ai) Ti) G E and /C(A 2 ; Tf) G E, then Ai = A 2 and T\ = T^. 

Proof. By the freshness conditions on big E ok. □ 

Lemma C.1T (Uniqueness of contexts). Assume E btx T ok. 

1. If a: Pl K i G T and a: P2 n 2 G T, then p\ = p 2 and = k 2 . 

2 . If c:(j )i G T and c: 0 2 G T, then i = 0 2 . 

Proof. By the freshness conditions on E btx T ok. □ 

Lemma C.18 (Determinacy of type constants), //big S ok, E be H : Ai; A' x ; Hi, and 
E be H : A 2 ; A' 2 ; H 2 , then A x = A 2 , A[ = A' 2 , and Hi = H 2 . 

Proof. From Lemma C.16. □ 

Lemma C.19 (Values do not step). There exists no r such that E; F b v —> r. 

Proof. By induction on the structure of v. □ 

Lemma C.20 (Determinacy). 

1. If E; T by t : Hi and E; T by t : k 2 , then Hi = n 2 . 

2 . If E; T bo 7 : 4 >i and E; T bo 7 : then (j>i — f> 2 . 

3 . If E; T b T —> <J i and E;Tbr —> cr 2 , then cri = cr 2 . 

Proof. By mutual induction, appealing to Lemma C.17, Lemma C.18 (which requires 
a use of Lemma C.9 first), and Lemma C.19. □ 
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C.5 Vectors 

Lemma C. 21 . If E; T by r : k and E; T bev if : A [r/a], then E; T bev t, if : a: Re \n, A. 
Proof. By induction on E; F bev if : A[r/a]. 

Case Cev_Nil: In this case, if and A are both empty, and so we are done by 
Cev_Nil and Cev_TyRel. 

Case Cev_TyRel: We now have if — if , u and A = A', b: Re \n 0 , with E; T b y a : 
K 0 [r/ a \[if /dom(A / )] and E; T bev if : A'[r/a]. The induction hypothesis gives 
us E; T bev r, if' : a: Re \K, A'. We are done by Cev_TyRel. 

Other cases: Similar. 


□ 

Lemma C.22. If E; Rel(T) by r : k and E;T bev if : A[r/a], then E; T bev r,if : 

a: lrrel«, A. 

Proof. Similar to previous proof. □ 

Lemma C.23. If E; Rel(T) bo 7 : <f> and E; T bev if ■ A[ 7 /c], then E; T bev 7 V : 

c\(f, A. 

Proof. Similar to previous proof. □ 

Lemma C.24. //E;T bee if ’ A and E;T by t : n[iff dom(A)] ; then E;T bee '0, T : 

A, a: Re i«;. 

Proof. By induction on E; T bee ' l f '■ A. 

Case Vec_Nil: In this case, if and A are both empty, and so we are done by 
Vec_Nil and Vec_TyRel. 

Case Vec_TyRel: We now have if — a,if' and A = b: Re \Ko,A' with E;T by 
a : Ko and E;T bee V’ ; A '[a/b\. We know, by assumption, that E;T by t ■ 
«[V’/dom(A)]. This expands to E;T by t : K,[a/b][if /dom(A')] (noting that 
Lemma C.12 assures us that a has no variables in dom(A') free). We can thus 
use the induction hypothesis to get E; T bee : A'[cr/6], a: Re \n[cr / b\, or, 

equivalently, E; T bee P , t ■ (A', a: Re \K)[cr/b\. We are done by Vec_TyRel. 

Other cases: Similar. 


□ 

Lemma C.25. //E;T bee V’ : A and E;Rel(T) by r : «[V’/dom(A)], then E; T bee 
if,r: A, a:, rre |K. 
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Proof. Similar to previous proof. □ 

Lemma C.26. If E; T kec ip : A an d E; Rel(T) bo 7 : (p[ip/ dom(A)], then E;T bee 
ip, 7 : A, c:cj). 

Proof. Similar to previous proof. □ 

Lemma C.27 (Vec/Cev). We have E; T bee if : A if and only ifT,-, T bev ip : A. 
Proof. We’ll prove the forward direction first, by induction on the typing derivation: 
Case Vec_Nil: We are done by Cev_Nil. 

Case Vec_TyRel: By the induction hypothesis and Lemma C.21. 

Case Vec_TyIrrel: By the induction hypothesis and Lemma C.22. 

Case Vec_Co: By the induction hypothesis and Lemma C.23. 

The reverse direction is similar, appealing to Lemma C.24, Lemma C.25, and 
Lemma C.26. □ 

Lemma C.28 (Vector lengths). If E; T bee ip : then \ip\ = |A|. 

Proof. Straightforward induction on E; T bee ip ■ A. □ 

Lemma C.29 (Vector kinds). J/E; T bee ip : A, then for every ip e ip, we have one 
of the following: 

1. ip = r and E; T hf y t : k for some k 

2. ip = {t} and E; Rel(T) by r : k for some k 

3. ip — 7 and E; Rel(T) bo 7 : ^ for some (p 

The resulting derivation is smaller than the input derivation. 

Proof. Straightforward induction on E; T bee ip ■ A. □ 

Lemma C.30 (Application inversion). If E; T by rip : k where ip — ip 0 ,ip 1 , then 
E; T by ripQ : IfA. n 0 , E; T bee V’i : A an d — «o[;0i/dom(A)]. 

Proof. Straightforward induction on ip 1 . □ 

Lemma C.31 (Telescope application). If E; T b y t : HA. a and E; T bee ip : A, then 
E; T by rip : cr['0/dom(A)]. 

Proof. By straightforward induction on E;T bee ip '■ A. □ 

Lemma C.32 (Telescope instantiation). //E; T b 0 rj : HA. a ~ HA', o', (\/i, E; T b 0 
7 * : t, ~ t-), E; T bee t : A, and E; T bee r' : A', then E; T bo : (T[r/dom(A)( ~ 
cr / [r / /dom(A / )]. 
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Proof. By induction on the structure of the list 7 . 

Case 7 = 0: By Lemma C.28, we can see that A and A' must both be empty. We 
are done by assumption. 

Case 7 In this case, we know E; Y bee t 0 ,Ti : A and thus that A = 

a: Rei^o, A x with E;T by t 0 '■ ^0 and E;T bee 1% : A 1 [ 1 * 0 / a]. Similarly, we have 
E; T hfy Tg : k' q and E; T b ec r, : A\ [r'j d. We must show E; T bo (rj@j 0 )@ 7 y 1 : 
a[r 0 /a,ri/dom(A|||: ~ cr'^/a, r / 1 /dom(A' 1 )]. We can rewrite our assumption 
(expanding A and A') to be E; T bo V '■ TlaiReiKo, Ai. a ~ dlaiRei/dg, A(. a' and 
thus derive E;T bo ?7@7o : ’n(Ai[ro/a]). (cr[r 0 /a]) ~ Tt(A'jTg/a]). (cr'^o/ 0 ])- 
We can then use the induction hypothesis to get E; T bo (h@7o)@7 : 
cr[T 0 /a] [ri/dom(Ai)] ~ o' [r' Q /a] [r'j./dom (A(}|,-. { which (noting that t 0 cannot 
have any of the dom(Ai) free) is what we wish to prove. 


□ 

Remark. The above Lemma C.32 could be made more general, to work with II as well 
as ’ll. However, doing so would make the statement and proof more cluttered, and it 
is only ever needed with TL 

C.6 Substitution 

Lemma C.33 (Value substitution). If v is a value with a free variable a, then v[a/a\ 
is also a value. 

Proof. By the definition of values. □ 

Lemma C.34 (Substitution/erasure). L r J[L cr J/ a ] = L T [ <T / a ]J 

Proof. By induction on the structure of r. □ 

Lemma C.35 (Type substitution). Assume E; T by cr : ft. 

1. //E;T, a: p K, T' by t ■ k 0 ? then E; T, Y'[a/a] by r[cr/a] : Kq[o / a]. 

2. If E;T, a: p K, T' bo 7 : <t>, then E; r,r'[ff/a] bo 7 [cr/a] : cj)[a/a]. 

3. If E; T, a: p K , T' brop ok, then E; T, r'[cr/a] brop a] ok. 

4- //E; T, a: p K, T'; cr 0 : K > then E; T, T'fcr/a]; cr 0 [cr/a] a>lt[(r/a] : k[g/ a\. 

5. If E; T, a: p K, T' bee V’ : A, then E; T, V'[a/a] bee M. a I a \ '■ A[cr/a]. 

6. If E btx T, a\ p K, r ok, then E btx T, V'[a/a ] ok. 

7. If E; T, a: p K, T' b t—» t' , then E; T, T'[<j/a] b r[cr/a] — >r'[a/a]. 

Proof. By mutual induction. Some interesting cases are below. 
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Case Ty_Var: Here, we know r is some variable b. There are three cases to 
consider: 

Case b: Re \K, 0 G © We must derive Yi-,T,T'[cr/a] by b : h'o’rr/ab We will use 
Ty_Var. We establish S btx r, r'[a/o] ok by the induction hypothesis. 
Scoping (Lemma C.12) tells us that a ^ fv(/c 0 ), and so we are done by the 
fact that b: Re \K 0 e T. 

Case b = a: By weakening (Lemma C.10). 

Case b: Re \K 0 e T': Once again, we get E btx r,r'[cr/a] ok by the induction 
hypothesis. Furthermore, we get b: Re \KQ[a/a\ € Y'[a/a ] from b: Re \K 0 G F'. 

Case Ty Con: By Lemma C.12, Lemma C.9, and induction. 

Case Alt Match: We adopt the metavariable names from the rule: 


E be H: Ai; A 2 ; H' A 3 , A 4 = A 2 [cr/dom(Ai)] 
dom(A 4 ) = dom(A') 

match {dom(A 3 )} (types( A 4 ); types( A')) = Just6> 

E; T by t : HA 3 , c:t 0 ~ dom(A 3 ). k 


E; T; TIA'. H'a\^ t H -at: « 


Alt _ Match 


We will use Alt_Match to prove our desired conclusion. Several premises are 
unchanged. The remaining ones we will have to prove: 


A 3 , A 4 = A 2 [cr[cr/a]/dom(Ai)]: By our choice of A 3 = A 3 [cr/a] and A' 4 = 
A i[(j/a\. 

match{ dom (A 3 )}(types(A 4 [cr/a]);types(A / [cr/a])) • Just#': We can freely choose 
#', but we still need to make sure that the match succeeds. This is by 
Property C.15. 


Case Co_Var: Similar to Ty_Var. 

Case Co_PiTy: We adopt the metavariable names from the rule (renaming the 
variable to be substituted to b): 


S; r bo rj : ^ Type^Type K2 

_ E; T, g Wl bo 7 Ty pe^T yP e ^ _ 

E; T bo Ra: p rj. 7 : (na: p Ki. 07) ~ (na: p «; 2 . (<r 2 [a > sym77/a])) 


Co_PiTy 


The induction hypothesis gives us: 


• E; r, r'fcr/6] bo vW/b\ : K\[<j/b] ~ k 2 [ct/&] 

• S; L. V[a/b\. a: Re \Ki[a/b\ bo 7 W/b\ ■ cn[cr/b] ~ cr 2 [cr/&] 
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By Co_PiTy, we get 


E;r,r'[(j/&] bo Ua: p rj[a/b\. ^[cr/b] : 

(Ua: p ni[a/b\. <Ti [a/b]) ~ {Iia\ p K 2 [a/b}. (a 2 [a/b][a > sym.rj[a/b]/a])) 

All that remains to show is that cr 2 [a/b][a > symr 7 [cr/ 6 ]/a] = a 2 [a > 
symr)/a][&/b], but this follows from the fact that a ff a, guaranteed by the 
Barendregt convention. We are done with this case. 

Case Co_PlCo: We adopt the metavariable names from the rule: 


E; T bo Vi : T i ~ r 2 E; r bo r] 2 : G\ ~ u 2 
E; r, C-.Tl ~ (Ti bo 7 : «1 Wpe^Type ^ c # 7 

_ V3 = Vi j cgsymTfr _ 

E; T bo lie: (771 ,772)- 7 : (IIc:ti ~ a v «i) ~ (nc:T 2 ~ a 2 . (k 2 [W c D) 


Co_PiCo 


For the most part, this follows the pattern of case Co_PiTy, but we must make 
sure that c # 7 [<r/a]. This fact follows from the Barendregt convention, which 
asserts that c cannot appear in a. 

Other cases: By the induction hypothesis, using Lemma C.33 for certain step rules, 
and using the Barendregt convention to rearrange substitutions (as in the 
Co_PiTy case). 


□ 

Lemma C.36 (Coercion substitution). Assume E; T bo 7 : </>• 

1. If E; T, c:<j), C ht y r : k 0 , then E; T, r'[ 7 /c] by t[ 7 /c] : k 0 [ 7 /c]. 

2. If E; T, c:(j), V bo V ■ ft, then E; T, r'[ 7 /c] bo V[l/c] : 4>'[l/c\. 

3. If E; T, c:0, I v brop <f>' ok, then E; F. r'[ 7 / c] b rop #[ 7 /c] ok. 

4- If E; T, c:(j), T'; cr 0 b° t : K > then E; T, F'[b/c]; cr 0 [ 7 /c] c] : /c[ 7 /c]. 

5. If E; T, c:</>, C bee ^ : A, then E; T, P[ 7 /c] bee t%/c] : A[ 7 /c]. 

A If E btx r, c:0, r ok, then E btx F, r'[ 7 /c] ok. 

7. If E; T, c:0, F^t —» r' , then E; F, r'[ 7 /c] b t[ 7 /c] —> t'[ 7 /c]. 

Proof. Similar to proof for Lemma C.35. □ 

Lemma C.37 (Vector substitution). If E; T bee V’ : A and E; T, A, T' by t : n, then 
E; T, T / ['0/dom(A)] by r[^/dom( A)] : /cji^dom(A)]. 


Proof. By induction on the structure of A. 
Case A = 0 : By assumption. 
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Case A = a 0 : Re \K 0 ,A': We know 0 = cr 0 ,0 , E; T by <7o : Kq, and E; T bee ■ 
A'[(Jo/a]. Lemma C.35 tells us E; T, A'[cr 0 /a], V[gq/ a] by t[( 7 o/o] : K,[a 0 /a\. We 
are done by a use of the induction hypothesis. 

Other cases: Similar. 


□ 


C.7 Type constants 

Lemma C.38 (Type-in-type), //big E ok, then E; 0 by Type : Type. 

Proof. Working backward, use Ty_Con so that we must show the following: 

E be Type : 0; 0; Type: By Tc_TYPE. 

E btx 0 ok: By Ctx_Nil. 

E; 0 bee 0 : 0: By VEC_NlL. 

We are thus done. □ 

Lemma C.39 (Telescopes). If E btx T, A ok, then E; T, A bee dom(A) : A. 

Proof. Proceed by induction on the structure of A. 

Case A = 0: By Vec_Nil. 

Case A = a: Re \K, A': We must show E; T, a: Re \K, A' bee o, dom(A / ) : a: Re \K, A'. By 
Vec_TyRel, we must show E; T, a: Re \K, A' by a : k and E; T, a:R e |ft, A' bee 
dom(A') : A'. The first is by Ty_Var and the second is by the induction 
hypothesis. 

Other cases: Similar. 


□ 

Lemma C.40 (Type constant telescopes). If big E ok and E be H : Ai; A 2 ; H', then 
E btx Ai, A 2 ok. 

Proof. By case analysis on E be H : Ap A 2 ; H'. 

Case Tc_ ADT: Here Ai = 0 and A 2 = a:R e i« We see that E btx a:irrei^ ok from 
big E ok (SlG_ADT). A use of Lemma C.6 solves our goal. 

Case Tc DataCon: Here Ai = a: irrei K. We must show E btx a: irre \K, A 2 ok. From 
bg E ok, we see that E btx a^irrei^, ^2 ok (Sig_DataCon). 

Case Tc_Type: Here Ai = A 2 = 0. We are done by Ctx_Nil. 

□ 
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Lemma C.41 (Type constant kinds). If big E ok and E be H : Ai;A 2 ]H', then 
E; 0 ht y HAi, A 2 . H' dom(Ai) : Type. 

Proof. To prove E; 0 by TIAi, A 2 . H' dom(Ai) : Type, we will use Ty_Pi (repeat¬ 
edly). We thus must show E; Rel(Ai, A 2 ) by -H'dom(Ai) : Type. This, in turn, will 
be by Ty_AppRel (repeatedly). We thus must show 

E; Rel(Ai, A 2 ) by H' : ’IIRel(Ai). Type (We are being a bit more specific here than 
necessary.) Case analysis of E be H '■ Ai; A 2 ; H' gives us several cases: 

Case Tc ADT: Here, Ai = 0 and H' = Type, and we must show 
E; Rel(A 2 ) by Type : Type. According to Ty_Con we must show only 
that E btx Rel(A 2 ) ok, which follows from Lemma C.40 and Lemma C.6. 
Case Tc DataCon: Here, Ai = a:i rre iK and H' = T. We must show 
E; aiReiK, Rel(A 2 ) by T : TTaiReiTb Type. Using Ty_Con means we must 
show E be T : 0 ; a:R e iK; Type and E btx a: Re \K, Rel(A 2 ) ok. The latter 
comes from big E ok and Lemma C.40. The former comes directly from 
Tc_ADT. 

Case Tc_Type: By Lemma C.38. 

E; Rel(Ai, A 2 ) bee dom(Ai) : Rel(Ai) This last judgment expands out to be all the 
typing judgments we need in Ty_ AppRel. See Vec_TyRel. To prove this, 
we use Lemma C.39, meaning that we need only show E btx Rel(Ai, A 2 ) ok, 
which we get from Lemma C.40. We are done. 

□ 

Lemma C.42 (Type constant inversion). J/E;T by U{t} V ; : K > then: 

1 . E be H : A; H' 

2. E; Rel(T) bee T : a: Re \K 

3. A 1; A 2 = A [r/a] 
l E; T bee ■■ Ai 

5. k = n(A 2 [Vydom(A i)]).H't 

Proof. By Lemma C.30, Lemma C.31, and Lemma C.20, and inversion and application 
of typing rules. □ 

C.8 Regularity, Part II 

Lemma C.43 (Kind regularity). If E; T by t : k, then E; Rel(T) by k ■ Type. 

Proof. By induction on the typing derivation. 
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Case Ty_Var: By Lemma C.7 (and Lemma C.10). 

Case Ty Con: We’ll adopt the metavariable names from the rule: 

S lt c II : Ap A 2 ; W E btx T ok 

S; Rel(r) U t : ReKAt) 

E;T ^ %, : ’n(A 2 [r/dom(A 1 )]). H't 

Use Lemma C.9 to get big E ok. Then use Lemma C.41 to get 
E;0 by ’IIAi, A 2 . H' dom(Ai) : Type. Repeated inversion on Ty_Pi 
gives us E;Rel(Ai) by IIA 2 . H' dom(Ai) : Type. Lemma C.10 gives us 
E; Rel(T), Rel(Ai) by ’nA 2 . H' dom(Ai) : Type. Lemma C.37 gives us 
E; Rel(T) b y , n(A 2 [r/dom(A 1 )]). H't : Type as desired. 

Case Ty_AppRel: We’ll adopt the metavariable names from the rule: 


E; r by Ti : Tla: Re \Ki. k 2 E; T b y t 2 : Ki 
E; T b y A t 2 : k 2 [t 2 /a] 


Ty_AppRel 


The induction hypothesis gives us E; Rel(r) by IIa:R e |/ci . k 2 : Type. Inversion on 
Ty_Pi gives us E; Rel(r), a:R e |fti by ft 2 : Type. Lemma C.6 gives us E; Rel(r) by 
t 2 : Ki, and then Lemma C.35 applies, giving us E; Rel(r) by ft 2 [T 2 /a] : Type as 
desired. 

Case Ty_AppIrrel: Similar to last case, noting that inverting Ty_Pi converts 
the Irrel to a Re I and without the need for Lemma C.6. 

Case Ty_CApp: Similar to previous case. 

Case Ty_Pi: By Lemma C.9 and Lemma C.38. 

Case Ty_Cast: By inversion. 

Case Ty_Case: By inversion. 

Case Ty_Lam: We’ll adopt the metavariable names from the rule: 


E; r, 5 by T : K 

E; r b y xs. T-.m.K 


Ty_Lam 


We must show E; Rel(r) by U<5. k : Type. Working backward, use Ty_Pi so 
that we must show E; Rel(T, 5) by K '■ Type, which is true by induction. 

Case Ty_Fix: We’ll adopt the metavariable names from the rule: 


E;T by t : Ha: Rei K. k 

-—— - Ty Fix 

E; T by fixr : k 

The induction hypothesis tells us E; Rel(r) by na: Re |K. k : Type. Inversion on 
Ty_Pi tells us E; Rel(r), a: Re i«; by « : Type. Lemma C.7 gives us E; Rel(r) by 
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k : Type as desired. 

Case Ty_Absurd: Immediate. 

□ 

Lemma C .44 (Proposition regularity). //E;T bo 7 : (j), then E; Rel(r) h^ rop (f) ok. 
Proof. By induction on the typing derivation. 

Case Co_Var: By Lemma C. 8 , Lemma C.9, and Lemma C.10. 

Case Co_Refl: Immediate. 

Case Co_Sym: By induction. 

Case Co _Trans: By induction. 

Case Co_ Coherence: Immediate. 

Case Co_Con: Immediate. 

Case Co_AppRel: Immediate. 

Case Co_AppIrrel: Immediate. 

Case Co_CApp: Immediate. 

Case Co_PiTy: We adopt the metavariable names from the statement of the rule: 


E; T bo r) : Kl T yP e ~ T y P e K2 

E; T, a: Re ,Ki bo 7 : a x T yP e ~ T yP e a 2 

E; r bo na: p r). 7 : (Ua: p Ki.ai) Type^Type (na: p K 2 - (cr 2 [a > sym rj/a])) 


Co_PiTy 


The induction hypothesis (and inversion) give us the following: 

• E; Rel(r) by «i : Type 

• E; Rel(r) by ft2 : Type 

• E; Rel(r), a: Re |fti by <T\ '■ Type 

• E; Rel(r), a: Re i/ci by 01 : Type 

We can straightforwardly use Ty_Pi to show that E; Rel(r) by Ha: p Ki.ai : 
Type. Choose a fresh b. We know E btx Rel(r), a: Re |fti ok by Lemma C.9. 
We can then use Ctx_TyVar (with Lemma C. 6 ) to show that S btx 
Rel(r), &: Re |ft 2 , o^Rei^i ok (along with a little inversion and rebuilding to re¬ 
order the variables). We established above that E; Rel(r), a: Re |fti by cr 2 : 
Type. Use weakening, Lemma C.10, (here and elsewhere in this case) to 
get E; Rel(r), 6: Re i«: 2 , a: Re |«;i by cr 2 : Type. We can use Co_Sym to see 
that E; Rel(r), 6: Re iK 2 bo sym 77 : k 2 ~ fti and then Ty_Cast to see that 
E; Rel(r), b-.Re\ k 2 by b>sym.r] : K\. Lemma C.35 then gives us E; Rel(r), &: Re |ft 2 by 
a 2 [b > sym 77/a] : Type. Use Ty_Pi to get E;Rel(r) by L lb: p k 2 . {cr 2 [b > 
sym 77/a]) : Type and ct-equivalence to get E;Rel(r) by ^la: p n 2 . (<r 2 [a > 
sym rj/a]) : Type. We are done by Prop_Equality. 
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Case Co_PlCo: We adopt the metavariable names from the statement of the rule: 


S;r Ico » 7 i : ri K3 ~ K4 T2 E; T ho 772 : 07 * 5 ~ K6 <j 2 

E; r, c:n K3 ~ K5 07 ho 7 : «i T yp e ~ T yp e K 2 c # 7 

_ ??3 = 7 ?i 9 c$ sym 772 _ 

E;T ho nc:(r/i, 772)- 7 : (IIc:ti K3 ~ K3 07.*7) Type^Type (nc:r 2 K4 ~ K « cr 2 . («2[%/c])) 

The induction hypothesis (and inversion) give us the following: 


C0P1C0 


• E; Rel(T) by : k 3 

• E; Rel(T) by t 2 : 

• E; Rel(T) b y 04 : k 5 

• E; Rel(T) b y 02 : k 6 

• E; Rel(T), c:ri ~ 07 b y k 1 : Type 

• E; Rel(T), c:ri ~ cri by ft2 : Type 

We can straightforwardly use Ty_Pi to show that E; Rel(r) by IIc:ri ~ 07. : 

Type. Choose a fresh b. We know E btx Rel(T), c:t\ ~ 04 ok by Lemma 
C. 9 . We can then use Ctx_CoVar (with Lemma C.6) to show that E btx 
Rel(T), c 2 :t 2 ~ 04, c:t x ~ 04 ok (along with a little inversion and rebuilding to 
reorder the variables). We also know E; Rel(T), 0:74 ~ 07 by ^2 : Type. Use 
weakening, Lemma C. 10 , (here and elsewhere in this case) to get E; Rel(r), c 2 :t 2 ~ 
02, c:ri ~ a 1 by ft2 : Type. We can use typing rules straightforwardly to see 
that E; Rel(T), c 2 :r 2 ~ 04 bo ?7i 9 c 2 9 sym 772 : 74 ~ <j\. Lemma C .36 then gives 
us E; Rel(T), c 2 :t 2 ~ a 2 by ^[vi 9 c 2 9 sym r} 2 /c\ : Type. Use Ty_Pi to get 
E;Rel(r)h w I 1 c 2 :t 2 ~ 04. (n 2 [r]i 9 c 2 9 syrnr/ 2 /c]) : Type and a-equivalence to 
get E; Rel(T) by nc:r 2 ~ 02. (« 2 [r/i 9 0 9 sym772/0]) : Type. We are done. 

Case Co_Case: Immediate. 

Case Co_Lam: We adopt the metavariable names from the statement of the rule: 
E ; rho7?:Kl TyPe ~ TyPe K2 

E; T, a: p K X ho 7 '■ n CTl ~' 72 r 2 
E; T, a: p K 1 by n : cri E; T, a: p «i h y r 2 : cr 2 

E; r ho Aa: p 7/. 7 : Aa: p /«i. 77 <n~na: p K 2 . (<r 2 [a>sym77/a]) Aa: p K 2 . (r 2 [a > sym77/a]) ~ 

We can use Ty_Lam to get E; T b y Aa: p «4. 74 : IIa: p Ki. 04. Proceeding similarly 
to the case for Co_PiTy, we can get E; Y by Aa: p 7c 2 . (r 2 [a > sym77/0]) : 
na: p K 2 . (04 [a > sym 77/a]) and we are done by Lemma C. 6 . 

Case Co_CLam: Similar to previous case and the case for Co_PlCo. 

Case Co_Fix: Immediate. 

Case Co_Absurd: By induction and Ty_Absurd. 

Case Co ArgK: By induction, inversion, Lemma C. 9 , and Lemma C. 7 . 

Case Co_CArgK 1: By induction, inversion, Lemma C. 9 , and Lemma C.8. 
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Case Co_CArgK2: Similar to previous case. 

Case Co_ArgKLam: Similar to case for Co_ArgK. 

Case Co_CArgKLam1: Similar to case for Co_CArgK1. 

Case Co_CArgKLam2: Similar to previous case. 

Case Co_Res: Immediate. 

Case Co_ResLam: Immediate. 

Case Co_InstRel: We adopt the metavariable names from the statement of the 
rule: 


E; T bo 7 : na: Re |Ki. <Ti ^ 
E; T bo r] : Ti Kl ~ K2 T2 


nfllRel^- CT2 


Co InstRel 


E; T bo 7@r7 : a ] ~ ct 2 [t 2 / a ] 

We will prove that (Ji[t\/ a] is well-typed; the proof for a 2 [t 2 / a] is similar. The 
induction hypothesis (and some inversion) tells us E; Rel(T) by na: Re |Ki. 0\ : 
Type. Further inversion gives us E; T, a: Re |fti by (J \ ■ Type. The induction 
hypothesis and an inversion also gives us E; Rel(r) by A : K\. Lemma C.35 gives 
us E; Rel(T) by /a] : Type as desired. 

Case Co_InstIrrel: Similar to previous case. 

Case Co_CInst: Similar to previous case. 

Case Co_InstLamRel: Similar to previous case. 

Case Co_InstLamIrrel: Similar to previous case. 

Case Co_CInstLam: Similar to previous case. 

Case Co_NthRel: Immediate. 

Case Co NthIrrel: Immediate. 


Case Co_Left: Immediate. 

Case Co_RightRel: We adopt the metavariable names from the statement of 
the rule: 


E; T 7 : n 07 T2 CT2 

E; r ty cn : Ki E; r t y cr 2 : k 2 E; T to V ■ «i Type ~ Type k 2 
E; T to right^ 7 : g\ Kl ~ K2 a2 


Co_RightRel 


The induction hypothesis tells us E; Rel(r) brop Tl 07 T2(72 <-,(< 

and thus inversion gives us E; Rel(r) by A &i ■ /^[cr/«]• We know E; T by if : 
'IIa:ReiKi. ac 3 , and thus we can invert the type application to get E; Rel(I’) by °\ '■ 
K\ as desired. We can similarly derive the type for < 72 , and we are thus done. 
Case Co_RightIrrel: Similar to previous case. 

Case Co_Kind: By Lemma C.43. 

Case Co Step: Immediate. 
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□ 


C.9 Preservation 

Lemma C.45 (Correctness of build_kpush_co). Assume S; T bev 0 '■ A[r/a], and let 
7 * = build_kpush_co(r 7 ;' 0 i...i_i) and 0' = cast_kpush_arg(0j; 7 ,). //E;Rel(r) bo : 
(lIA.cr )[r/a] ~ (IIA. cr)\f'"/a], then: 

1. E;Rel(T) bo build_kpush_co(? 7 ;0) : cr[r/a][V’/dom(A)] ~ a /dom(A)] 

2. E; T bev 0' ■ A[r'/a] 

Proof. Proceed by induction on E; r bev 0 : A[r/a]. 

Case Cev_Nil: In this case, both 0 and A are empty. We must prove 
E;Rel(r) bo build_kpush_co(r 7 ; 0 ) : a[r/a] ~ crpf'/a]. By dehnition, 

buiId_kpush_ 00 ( 77 ; 0 ) = V- We are done by assumption and Cev_Nil. 

Case Cev_TyRel: In this case, we have 0 = 0 o ,t o and A = A 0 , b :with 
E;T bev 0 O : A 0 [r/a] and E;T by t 0 : /c[r/a][0 o /dom(A o )]. We can see that 
build_kpush_co(r 7 ; 00 , t 0 ) = let c := build_kpush_co( 77 ; 0 O ) in c@(t 0 ~ a r g kc 
To > argkc). The induction hypothesis tells us that E; Rel(r) bo c : 
(TI&iReiK. cr)[T/a][0 o /dom(A o )] ~ (TI&iReiK. cr)[T / /a][0 o /do r n(A o )]. We can thus 
deduce the following: 

• E; Rel(T) bo argkc : «[T/a] [0 o /dom(A o )] ~ k[t' fa][ip' 0 /dom(A 0 )\ 

• E; Rel(r) by t 0 > argk c : K,[r'/a][ip o/dom(A 0 )] 

• E; Rel(T) bo To ~argk c t 0 > argk c : t 0 ~ t 0 > argk c 

• E; Rel(T) bo c@(t 0 ^ arg kc t 0 > argk c) : a[T/a][0o/dom(A o )][To/&] ~ 
a \T > /^\ [V’o/dom ( A 0 )] [t 0 > argk c/6] 

Note that cast_kpush_arg(T 0 ; c) = t 0 > argkc and thus that we can say 
Tq = To [> argk c. Noting that the 0 O cannot have b free due to the Barendregt 
convention, we can rewrite the substutition [0 o /dom(A o )][T O /&] as [0/dom(A)] 
and rewrite the last judgment above as E;Rel(r) bo build_kpush_co(? 7 ; 0) : 
a[r/a] [0/dom(A)] ~ a[r'/a][ip /dom(A)], which is what we are trying to prove. 
We are done proving result (1). 

For result (2), we must prove E; F bev 0o, r o > argkc : A 0 [t'/ a], b:R e \K[r'/a\. 
This fact comes from a straightforward use of Cev_TyRel. 

Case Cev_TyIrrel: Similar to previous case. 

Case Cev_Co: In this case, we have 0 = 0 o ,7o and A = 

A 0 , c o :0o with E;T bev 0o : A 0 V/a] and E; Rel(T) bo 7 o : 

0o[T/a][0 o /dom(A o )]. We can see that build_kpush_co(r 7 ; 0 0 , 70 ) = let c : — 


236 




build_kpush_00(77; V’o) c @(7o, s y m (argk x c) 9 70 9 argk 2 c). The induction 

hypothesis tells us that E; Rel(T) ho c : fnc 0 :d>o- cr)[r/a][' 0 o/d° m (Ao)] ^ 
{ y Ilc 0 :(j)o.cr)[T'/a][^> 0 /d o m(A 0 )\. Let (f > 0 = 07 ~ cr 2 . We can thus deduce the 
following: 

• E;Rel(T)_ ho sym (argk, c) : dom(A 0 )] ~ 

cri[T/a\{ip 0 /dom(A 0 )\ 

• E; Rel(T) ho argk 2 c : a 2 [r/a][if 0 /dom(A 0 )] ~ <T 2 t^^[^i/dom(Ao j 

• E;Rel(T)^ho sym (argk x c) § y 0 I argk 2 c : rr, V/a [i^/dorr^A,,))-. ~ 
cr 2 [T7a][ : 0o/dom(Ao)] 

• E;Rel(T) ho c@( 7 0 , sym (argk x c) $ j 0 ° 9 argk 2 c) : 

v[T/a\bP o/do m (Ao)][ 7 o/coJ ~ ^/^]jj&/dom(Ao)][sym (arg^ § 

70 ? argk 2 c/co] 

Note that cast_kpush_arg(7 0 ; c) = sym (argk x c), 70 9 argk 2 c and thus that 
we can say 70 = sym (argk x c) 9 70 9 argk 2 c. Noting that the if 0 cannot 
have Co free due to the Barendregt convention, we can rewrite the substitution 
[' 0 o /dom(A o )] [70/co] as [■ 0 /dom(A)] and rewrite the last judgment above as 

E;Rel(T) ho build_kpush_00(77; 7 ^) : a \ T / a . [r/dom(A)( ~ crf^r'/^a][?/; / /dom(A.)], 

which is what we are trying to prove. We are done proving result ( 1 ). 

To prove result ( 2 ), we must show E; T hev L 0 , sym (argk, c) 9 70 9 argk 2 c : 
A 0 [r'/a], Cq:(/) 0 [t'/ a], which we get from a straightforward use of Cev_Co. 


□ 


Remark. Lemma C .45 could also be rewritten to work with n, but with no need. 
Theorem C.46 (Preservation). If E; T by t : k and E; T h t —> t', then E; T hy t' : 

K. 


Proof. By induction on the typing derivation. 

Case Ty_Var: Impossible, as variables do not step. 

Case Ty Con: Impossible, as constants do not step. 

Case Ty_AppRel: We now have several cases, depending on how the expression 
has stepped: 

Case S_BetaRel: By Lemma C. 35 . 

Case S_App_Cong: By induction. 
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Case S_PushRel: We adopt the metavariable names from the statement of 
the rule: 


E; Rel(r) bo 7 0 : fIa: Re |AC. a ~ na: Re |/d. o' 

71 = sym (argk7o) 7 2 = 7 0 @(t > 71 ^ sym71 r) 

E; T b (n > 70) r —)■ v (r > 71) > 72 


S_PushRel 


Inversion on E; T by (n > 70) r : /c 0 gives us E; T by r : /d and E; T by v : 
II a\ p K. a. Straightforward application of typing rules gives us E; Rel(r) bo 
71 : k' ~ k and E; Rel(r) bo 72 : ct[t > 71/a] ~ cr'[r/a]. We can then 
derive E; T by t > 71 : k and thus E; T by v (r > 71) : a[r > 71/a] and 
E; T by v (t > 71) > 72 : <j'[t/ a] as desired. 


Case Ty AppIrrel: We now have several cases: 


Case S_BetaIrrel: By Lemma C. 35 . 

Case S_App_Cong: By induction. 

Case S PushIrrel: Similar to the case for S_PushRel. 


Case Ty CApp: We now have several cases: 


Case S_CBeta: By Lemma C. 36 . 

Case S_App_Cong: By induction. 

Case S_CPush: We adopt the metavariable names of the rule: 


E; Rel(r) bo 7 o : n C :<f>.a 

71 = argk x 70 72 

rf = 7 i 9V 9 s ym72 

S; r b (u > 7o) V - 

We can see that E;T by (v > 7o) V ■ ^'[v/ c ]- Let (f) — T\ ~ t 2 and 
<\>' — T3 ~ T4. Inversion and application of typing rules tells us the following: 

• E; T by v : II c:(f>. a 

• E; Rel(r) bo V '■ ^3 ~ ^4 

• E; Rel(r) bo 7i : T i ~ r 3 

• E; Rel(r) bo 72 : r 2 ~ r 4 

• E; Rel(r) bo rf ■ R ~ r 2 

• E; Rel(r) bo 73 : v[rf/c] ~ v'bl/4 

• E;T by vrf : cr[rf/c\ 

• E;T by v rf > 73 : a'\r]/c\ 

Note that the last fact proves this case. 

Case Ty Pi: Impossible, as Il-types do not step. 

Case Ty Cast: We now have several cases: 
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alt — H — y Tn 

-=—=-=-=- S Match 

E; T hi case* H^} ip of alt —* To ip (H^} ip §' • 

Inversion and typing rules tell us the following: 

• E; T ht y H{y} ip : ’I1A'. H'a (premise of Ty_Case) 

• Using Lemma C. 42 : 

— E hf c H : a:i rre iK; A 2 ; H' 

- A 0 ,Ai ^A 2 [r/a] 

- E; L h^ec U : A 0 

— A' = A 1 [ , 0/dom(A o )] and a = r (Lemma C. 20 ) 

• The premises of Alt_Match (also using Lemma C. 18 ): 

- A 3 ,A 4 = A 2 [t/c] 

- |A 4 | = [Ail 

- E; T hfy t 0 : HA 3 , c:H[ r y ip ~ H^} dom(A 3 ). k 

• A 3 = A 0 and A 4 = A 4 (from |A 4 | = |A 4 | and the definitions of A 0 , 
Ai, A 3 , and A 4 ) 

• E; T ht y t 0 : HA 0 , c\H^y ip ~ //{t} dom(A 0 ). k (rewriting) 

• E; T hty To ip '■ Wp: H{ T ) ip ~ H{t} ip- K (Lemma C. 31 , where the k needs 
no substitution by Lemma C. 12 ) 

• E;T by To ip {H{t} ip) '■ k (Co_Refl and Ty_CApp, where the k 
needs no substitution by Lemma C. 12 ) 

Note that this last fact proves this case. 
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Case S_ Default: We adopt the metavariable names of the rule: 


alti = —^ o’ no alternative in alt matches H 

E; T b case K ip of alt —> a 


S_ Default 


By Ty_Case, the redex has kind k: inversion also gives us E;r;cr 0 ^it 

_ —)■ <7 : k. Inverting Alt_ Default gives us our goal. 

Case S_DefaultCo: Similar to previous case. 

Case S_Case_Cong: By induction. 

Case S_KPush: We adopt the metavariable names of the rule: 


E be H : a:\rre\K; A; H' A = Ai, A 2 n = |A 2 | 
k = ’na:i rre |K, A. H' a 
a = , U(A 2 [t/ a][ip/dom(Ai)]). H't 
a ' = , n(A2[r / /a]['0 / /d° r n(Ai)])- H't 1 
E; Rel(r) bo V ■ a ~ o’ 

E; Rel(r) bee t' : a: R e |it 

Vi, 7 i = build_kpush_co((/c)@(nths(res n 77 ));Vh...i-i) 

Vi, |§' — cast_kpush_arg(-0j; 7 *) 

H —> k' G alt 

E; T b case K0 (H^} ip) l> V °f t case K0 H^'} ip of alt 


S_KPush 


Note that we need to prove only that the type of {H^} ip)>r] matches that 
of H {¥} iP , namely Tf(A 2 [r / /a ][ip /dom(Ai)]). H't'. We can derive these 
facts: 

• E;T by H {n ip : TI(A 2 [f r /a][V’/dom(Ai)]). H't (by inversion of the 
typing judgment on the redex) 

• E; T by H{ T } : TI(Ai[r/a], A 2 [r/a]). H't (by Lemma C .30 followed by 
inverting Ty_Con) 

• E; T bee ip ■ Ai[t/o] (also from Lemma C. 30 ) 

• E; T bee V : a:Relit (by inversion) 

• E; Rel(r) bee r' : a: Re ,k (from S_KPush) 

• E; Rel(r) bo res” rj : H't ~ H't' (with the well-formedness of f and 
t' telling us that the r and t' do not have any variables in dom(A 2 ) 
free) 

• Vi, 3 %, E; Rel(r) by t* : /Cj (by Lemma C. 29 ) 

• Vi, zk', E; Rel(r) by t' : k\ (by Lemma C. 29 ) 

• Vi, E; Rel(r) bo nth* (res” rj) : t* ~ r| (from Co_NthRel) 

• E; T by k : Type, recalling that k = ’na:i rre iit, A. H'a (by Lemma C. 9 , 
Lemma C. 41 , and Lemma C. 10 ) 

• E; T bo <k) : k ~ k (by Co_Refl) 

• E;F bo (/c)@(nths (res” rj)) : (TIAi, A 2 . H'a)[T/a] ~ 
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(TIAi, A 2 . H' o)[t'/ a\ (by Lemma C. 32 ) 

• E; T bev '■ Ai [r/a\ (by Lemma C. 27 ) 

• E; T bev ip' : A 1 [r / /a] (by Lemma C. 45 ) 

• E; T bee ip' : Ai[r'/a] (by Lemma C. 27 ) 

• E;T hfy : ’n(A x [r 7 a],A 2 [r^a]).//V (by a use of Ty_Con, 
along with Lemma C. 9 ) 

• E; T by : , U(A 2 [t'/ a]ff /domiA^]). H'r' 

This last fact is what we are trying to prove, and so we are done. 

Case Ty_Lam: We now have several cases: 

Case S_IrrelAbs_Cong: By induction. 

Case S_APush: We adopt the metavariable names from the rule: 

7 i = na:i rre i(/c). 7 72 = n ~(T yP e> t 2 

ri = na:| rre |K. (/ci[a > sym(«)/a]) t 2 = Ua: irrei K. k x g APuSH 
E; T b Aa:i rre |K. (u > 7) —> (Aa:i rre |K. v) > (71 ? 72) 

Inversion and typing rules then give us the following facts: 

• E; T hjy Aa:| rre |K. (v > 7) : Ila\\ rre \K. K\ 

• E; T, a:i rre |/c by v > 7 : K\ 

• E; Rel(r), a:Rei«; bo 7 : Ro ~ «i 

• E; T, a\\ rre \K by v : k 0 

• E; T by Aa:| rre |/c. v : IJa:| rre |K. /c 0 

• E; Rel(r) by R : Type (by Lemma C .9 and Lemma C. 7 ) 

• E; Rel(T) bo («} : k ~ k (by Co_Refl) 

• E; Rel(r) bo na:i rre i(/c). 7 : rja:i rre |K. /Co ~ Ila\\ rre \K. (/c x [a > sym(/t)/o]) 
(by Co_PiTy) 

• S;Rel(T)b y na:| rre |K. (/ci[a > sym(/c)/a]) : Type (by Lemma C. 44 ) 

• E; Rel(T) b y na:| rre |/c. /c x : Type (by Lemma C. 43 ) 

• E; Rel(T) bo (na:i rre i/c. (/ci[o > sym (/c)/a])) ~(T ype > (na:i rre |/c./c x ) : 
(na:i rre |/c. (/ci[o > sym(/c)/o])) ~ (rjo:i rre |/c. /ci) (by Co_Coherence) 

We can then conclude, by Co_Trans and Ty_Cast, that the result has 
the same type, na:i rre i/c. K\ as the redex. 

Case Ty_Fix: We now have several cases: 

Case S_Unroll: We adopt the variable names from the rule: 


r = Aa:Rei/c. a 
E; T b fixr —» o’[fix r/a] 


S_ Unroll 


We can then derive the following: 
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• E; T ht y \a: Re \n. cr : IlaiReifc. k (by inversion) 

• E; r, a:R e \K by cr '■ k (by inversion) 

• E; T hf y fix (Xa: Re \K. a) : k (by Ty_Fix) 

• E;T hty cr[fix (Aa: Re |R. cr)/a] : k (by Lemma C. 35 ) 

This last judgment is what we are trying to prove; we are done. 
Case S_Fix_Cong: By induction. 

Case S_FPush: We adopt the metavariable names from the rule: 


7 1 = 7 o@(a ~ 72 « > 72) 9 symys 

72 = argk 70 

E; T hi fix ((Aa: Re i/c. cr) > 70) —f (fix (Aa: Re i«. (cr > 71))) > 72 


S_FPush 


We can derive the following facts: 

• E; T hfy fix ((Aa:R e |/c. cr) > 70) : K\ (conclusion of Ty_Fix) 

• E; T hfy (Aa: Re |K. cr) > 70 : na: Re |/Ci. Ri (premise of Ty_Fix) 

• E; Rel(r) hf Q 70 : k 0 ~ na: Re |/Ci. (inversion on Ty_Cast) 

• E; T hfy Aa: Re |/Y a : k 0 (same inversion) 

• E; r hfy Aa:Rei/Y cr : IIa:Rei/c. R2 (inversion by Ty_Lam) 

• Ko = rja:R e |/Y K2 (Lemma C.20) 

• E; r, a: Re \K hf y a : K2 (inversion by Ty_Lam) 

• E;Rel(T) hf 0 y 0 : (na: Re i«;. /c 2 ) ~ (na: Re |/Ci. «i) (substitution) 

• E; Rel(r) argk 70 : k ~ (Co_ArgK) 

• 72 = argk 70 (premise of S_FPush) 

• E; T, a: Re \K hf y a > 72 : Ki (Ty_Cast) 

• E; T, a: Re \K hf Q a « 72 a > 72 : a ~ a > 72 (Co_COHERENCE) 

• E; T, a: Re |R hf 0 7 0 @(a « 72 a > 72) : k 2 ~ Ri[a > 72/a] (Co_InstRel) 

• E; Rel(r) hf y na: Re |/Ci./Ci : Type (Lemma C.43) 

• E; Rel(r), a:Rei/ci hf y k± : Type (inversion on Ty_Pi) 

• E; Rel(r) hf y : Type (Lemma C.7 and Lemma C.10) 

• K\[a > 72/a] = (Lemma C.12, noting that a # Ki) 

• E; T, a: Re |R hf 0 7 0 @(a f« 72 a > 72) : r 2 ~ (substitution) 

• E; r, a:R e |R hf 0 sym7 2 : K\ ~ k (Co_Sym with Lemma C.10) 

• 71 = 7o@(a « 72 a > 72) 9 sym7 2 (premise of S_FPush) 

• E; T, a: Re |R hf 0 71 : k 2 ~ k (Co_Trans) 

• E; T, a:R e |R hf y cr > 71 : k (Ty_Cast and Lemma C.6) 

• E; T hfy Aa:R e |R. (cr > 71) : na:R e |/u n (Ty_Lam) 

• E; T hfy fix (Aa: Re |R. (cr > 71)) : k (Ty_Fix) 

• E; T hfy (fix (Aa: Re |R. (cr > 7^)) > 72 : Ri (Ty_Cast) 

The last item proves this case. 

Case Ty_ Absurd: Impossible, as absurd 7 r does not step. 

□ 
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C. 10 Consistency 

Definition C.4T (Coercion erasure). Define the erasure of a type e — [tJ by the 
following function (including auxiliary functions): 

[aj = a 

L%}J = H m} 

[ti t 2 J = LnJ Ivij 
Ln{r 2 }j = Lr 1 J{Lr 2 J} 
lr 7 j = [ T J • 

[11(5 . tJ =n[(5J. [rj 

\j > i\ = L r J 

[case^rof alt\ = case^j [rj of [alt\ 

[X 8 .r\=X[S\.[r\ 

[fix tJ = fix [tJ 
[absurd 7 tJ = absurd • [tJ 

la-. P K J = a: p [n\ 

[c- 4 > J = •: L 0 J 

[ti K1 ~ K2 t 2 J = [TiJ 1**1 M [t 2 J 

[tt T J = 7T [tJ 

Notation C.48 (Erased types in consistency proof). The rewrite relation is defined 
only over erased types. We use a convention that the occurrence of a metavariable 
in a mention of the relation indicates that the metavariable represents an erased 
element. 

Notation C.49 (Reduction). 

• We write if if to mean Vi, ifi if\. 

• We write n -w r 3 t 2 to mean t\ t 3 and t 2 t 3 . 

• We write ~'»* to mean the reflexive, transitive closure of 

• We write n r 3 t 2 to mean n t 3 and t 2 r 3 . 

Lemma C.50 (Parallel reduction substitution). Assume ip ^ if . We can then 
conclude: 

1 . r[if/z\ -v* 

2 . <5 [- 0 /^] 
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Proof. By straightforward mutual induction on the structure of r/8. □ 

Lemma C.51 (Parallel reduction substitution in parallel). Assume ip 4> ■ 

1. If T\ r 2 , then Ti[ip/z\ r 2 [ip /z\. 

2. If Si S 2 , then 5i[ip/z] S 2 [ip'/z\. 

Proof. By induction on n t 2 /S\ S 2 . 

Case R_Refl: By Lemma C.50. 

Congruence rules: By induction. 

Case R_BetaRel: It must be that T\ = (\b: Re \Ki. t 3 ) t 4 and t 2 = T^r'Jb] where 
r 3 T 3 and T 4 t 4 . We must show that {\b: Re \Ki[ip/~z]. Ts[ip/z]) r 4 [ip/z] 
T 'ii T 4 /b}[v /z\. Proceeding by R_BetaRel, the left-hand-side steps to r 5 [r 6 / b\ 
where r 3 [ip/z\ r 5 and t,\[v{\ t 6 . (We can choose r 5 and r 6 .) We must 

thus show that t 5 [t 6 /&] = t^[t' 4 /b][ip /z\. First, we reorder substitutions to get 
T z[ T 'Jti\W /~z\ — Ts[l^ /z][t i[fp /z]/&], noting that b ff ip by the Barendregt 
convention. Choose r 5 = r 3 [/0 /z] and r 6 = /~z\. We must show that 

T 3 [ip/z\ t 5 and t^/z] r 6 ; expanding gives us that we must show r 3 [ip/z] 

r!>\ip /~z] and r 4 [ip/z\ T±[ip fz]. Both of these follow directly from the induction 
hypothesis, and so we are done. 

Case R_BetaIrrel: Similar to previous case. 

Case R_CBeta: By induction. 

Case R_ Match: It must be that: 

• Ti = case K ip 0 of alt 

• t 2 = t 4 ip Q • where H —>• r 3 e alt, t 3 t 4 , and ip 0 ip 0 . 

We must show that case^^i ip 0 [ip/z\ of alt[ip/z\ r 4 [ip'/z\ ip' (i ^fz\ •. 

Proceeding by R_ Match, the left-hand side steps to t 5 ip 0 • where T :i [ip/z] t 5 
and v G [ii>fz ip 0 , and we get to choose r 5 and ip 0 . We must show that 
TgV’o* — T 4 [fp /z\ip 0 [ip /z}». Choose t 5 = r 4 [ip /z\ and ip 0 = ip 0 [ip/z\. We 

must show that r 3 [ip/z] r 4 [ip /~z] and ip 0 [ip/z\ ipo^p /~z\- Both of these follow 

from the induction hypothesis, and so we are done. 

Case R_ Default: It must be that: 

• Ti = case K ip 0 of _ —>• cr 0 ; alt 

• t 2 — a' 0 where cr 0 a' 0 

We are done by the induction hypothesis. 

Case R Unroll: It must be that: 
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• Ti = fix(Aa: R eiKi.r 3 ) 

• t 2 = r 4 [fix (Aa: Re |K 2 -where /c 4 k 2 and t 3 r 4 . 

We must show that fix (\a:R e \Ki[if/z]. r 3 [if/z]) r 4 [fix (Aa:ReiK 2 . t 4 )/a\[if'/~z\. 
Proceeding by R_Unroll, the left-hand side steps to r 5 [fix (\a:R e \n 3 . r 5 )/a] 
where t 5 and K \ [if /z] « 3 . We must show that 

T5[fix (Ao:R e i ac 3 . 75)/ci] = T 4 [fix (Aa:Rei«; 2 . T 4 )/a ]['0 /z]. Reorder substitutions on 
the right to get 

T 4 [fix (Aa: Re i«; 2 . t 4 )/ a][if jz\ = r 4 [if /z][fix (AaiRei^^ /z\.r 4 [if /z])/a], 

where a ff if by the Barendregt convention. Choose t 5 = t 4 [/0 and k 3 = 
k 2 ['0 /z\. It remains only to show that r 3 [if/z] r 4 [if /z] and Ki[if/z] 
k 2 ['0 /~z\, both of which follow from the induction hypothesis. We are done. 


□ 

Lemma C.52 (Parallel repeated reduction substitution). If Ti t 2 and if if', 

then Ti[if/z\ r 2 [if /z\. 

Proof. By iterated induction on the lengths of the reduction chains. □ 

Lemma C.53 (Application reduction). If H^y if a, then a = Hy^yif where 
t ~'+ t 1 and if if . 

Proof. Straightforward induction on the structure of < 7 o = H{ T } if- □ 

Lemma C.54 (Local diamond). Let Ti denote an erased type and 5i an erased binder. 

1. If t 0 Ti and To r 2 , then there exists t 3 such that Ti t 3 t 2 . 

2. If <5 0 and S 0 S 2 , then there exists 83 such that <5 4 83 S 2 . 

Proof. By induction on the structure of r 0 /<5 0 followed by case analysis on the reduction 
of tq/8q. We ignore overlap with the R_Refl rule, as this is always trivially handled. 

Case t 0 = a: T\ = t 2 = t 3 = a. 

Case t 0 = R(r} : By induction. 

Case t 0 = (7\ o 2 ‘- We now have several cases: 

Case R_AppRel/R_AppRel: By induction. 

Case R_AppRel/R_BetaRel: It must be that: 

• t 0 = {Xa: p K 1 .a 3 )a 4 

• t 4 = (A a: p K 2 . a 5 ) cr 6 , where Ki k 2 , ct 3 a 5 , and cr 4 cr 6 , and 

• t 2 = a 3 [a 4 /a]. 
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Choose r 3 = ct 5 [<t 6 /a]. We must show T\ r 3 and r 2 t 3 . The first is by 
R_BetaRel. The second is by Lemma C. 51 . 

Case R_BetaRel/R_BetaRel: It must be that: 

• t 0 = (A a: p K.a 3 )a 4 

• T\ — a 3[0:4/ a], where cr 3 a' 3 and a 4 a' 4 

• T‘2 — a"[a"/a], where cr 3 <7" and er 4 a”. 

Using the induction hypothesis, we can get a 5 and cr 6 such that 

• (T3 (T5 (T3 

• a' 4 ^ a 6 o" 4 . 

Choose t 3 = cr 5 [<76/a]. We must show 03[04/a] cr 5 [a 6 /a] and 0 3 [n"/a] 

(7 5 [(7 6 /a]. Both of these follow from Lemma C. 51 . 

Case t 0 = (7i{(7 2 }: Similar to t 0 = <J\ cr 2 . 

Case To = (x •: We now have several cases: 

Case R_CApp/R_CApp: By induction. 

Case R_CApp/R_CBeta: It must be that: 

• To = (A»:K| ~ k 2 . (7 3 ) • 

• Ti = (A«:k 3 ~ k 4 . a 4 ) • where /c 3 , r 2 /c 4 , and cr 3 cr 4 . 

• t 2 = cr 5 where cr 3 cr 5 

The induction hypothesis gives us cr 6 such that cr 4 -w cr 6 cr 5 . Choose 
t 3 = (7g. We must show t 4 T3 and t 2 t 3 . The first is by R_CBeta. 
The second is immediate. 

Case R_CBeta/R_CBeta: By induction. 

Case t 0 = ILi. cr 0 : By induction and R_Pi. 

Case To = case* cr 0 of alt : We now have several cases: 

Case R Case/R Case: By induction and R_Case. 

Case R_Case/R_Match: It must be that: 

• t 0 = case,, //{„j 0 of //'-4, e’ 

• Ti = case*,/ H{a'} 0 of V where k k', a a', 0 0 , and 

e -w gf (appealing to Lemma C. 53 ) 

• t 2 — e'l 0 •. where Hi = R, e* e", and 0 -0 . 

Using the induction hypothesis, we can get e'" such that e' e'" e'/ and 

0 such that 0 0 0 . Choose t 3 = e '"0 •. We must show both 

Tj t 3 and t 2 t 3 . The first is by R_Match. The second is by repeated 
use of R_AppRel/R_AppIrrel/R_CApp. 

Case R_Case/R_Default: It must be that: 
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• r 0 = case K ip of _ —>• cr 0 ; alt 

• T\ = case*/ ip of _ —y a' 0 ; alt where k k', a a', ip -w ip , 
(To (Tq, and alt alt 

• t 2 = (Tq where cr 0 (Tq 

The induction hypothesis gives us e such that (Tq e ** cr'o. We can see 
that t i can step by R_Default (as the type constant H does not change), 
and thus that Ty e r 2 . We are done. 

Case R_Match/R_Match: It must be that: 

• t 0 = case K ip of alt 

• alti = H -A K\ 

• Tj — Ky X) • where and ip ip . 

• r 2 — k'{ ip • where /c 4 n'{ and ip ^ ip . 

The induction hypothesis gives us k'" and ip"' such that: 

• k[ k" 

• ip -w ip w ip 

Choose t 3 = <[//*] and we are done by Lemma C.51. 

Case R_Match/R_Default: Impossible, as the premises contradict each 
other. 

Case R_Default/R_Default: By induction. 

Case To = A5 0 . cr 0 : By induction and R_LAM. 

Case t 0 = fix cr 0 : We have several cases: 

Case R_Fix/R_Fix: By induction. 

Case R_Fix/R_Unroll: It must be that: 

• t 0 = fix(Aa: Re |/ci.(Ti) 

• Ti = fix (Aa: Re |ft 2 - cr 2 ) where Ky k 2 and <j\ <r 2 

• t 2 = cr 3 [fix (Aa: Re |K 3 . cr 3 )/a] where Ky k 3 and ay a 3 

The induction hypothesis gives us k 4 and (r 4 such that k 2 k 4 k 3 
and cr 2 -w (t 4 ^ <r 3 . Choose t 3 = <r 4 [fix (A a : R e i k 4 . cr 4 ) / a] . We must show 
Ti t 3 and t 2 t 3 . The first is by R_UNROLL, and the second is by 
Lemma C.51. 

Case R_Unroll/R_Unroll: It must be that: 

• t 0 = fix(Aa: Re |Ki.(Ti) 

• Ti = cr 2 [fix (Aa: R e|K 2 - cr 2 )/a] where Ky k 2 and Oy cr 2 

• t 2 = cr 3 [fix (Aa:R e |N 3 . cr 3 )/a] where Ky k 3 and cry cr 3 

The induction hypothesis gives us k 4 and <r 4 such that k 2 k a ^ k 3 and 
cr 2 -w cr 4 cr 3 . Choose t 3 = cr 4 [fix (Aa: Re |N 4 . cr 4 )/a] and we are done by 
Lemma C.51. 
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Case To = absurd 7 (To: By induction and R_ABSURD. 
Case So = a: p n 0 : By induction and R_TyBinder. 
Case <5 0 = •:ri ~ T\\ By induction and R_ CoBinder. 


□ 


Lemma C.55 (Confluence). Let Ti denote an erased type. If T\ T 2 and T\ W 1 t 3? 
then there exists T4 such that T2 T4 T3. 

Proof. Consequence of Lemma C.54. □ 

Lemma C.56 (II-reduction). IfUS.r a, then there exist S' and r' such that 
a = IW'. t', 8 S', and r r'. 

Proof. Case anlysis on 115. t a. □ 

Lemma C.57 (A- reduction). If XS.t a, then there exist 5' and r' such that 
a = A S', t', 5 S', and t t'. 

Proof. Case anlysis on A 5 . t a. □ 

Lemma C.58 (Matchable application reduction). If t _0 a. then there exist r' and 

0 ' such that a = r'jf', t t' , and 0 if'. 

Proof. Case analysis on r_0 a. □ 

Lemma C.59 (Coercion substitution/erasure). |_ r [ 7 / c ]J — L r J 

Proof. By induction on the structure of r. □ 

Lemma C.60 (Type constant kinds shape). //£;T hj y Rpfi} 0i : k x and £;T hty 
H{ti} V ; 2 : k "2 (where the lengths of 0 , and 0 2 are the same), then there exists a k such 
that fv(re) = {a} U {z}, k x = n[Ti/a,if 1 /z], and k 2 = K[r 2 fa, if 2 /z]. 

Proof. Lemma C.30 tells us that there exist and k 4 such that E; r by % l} : 
k, 3 and S; T h y H{ T2 } : k 4 . Inversion (via the only applicable rule, Ty_Con) 
then tells us that E b H : A 1 ;A 2 ',H', k 3 = ’n(A 2 [Ti/dom(Ai)]). H’ r x , 

and k 4 = ’n(A 2 [T 2 /dom(Ai)]). H't 2 . Lemma C.30 also tells us that E; T bee 
03 : prefix(A 2 [ri/dom(Ai)]) and E;T bee 0 2 : prefix(A 2 [T2/dom(Ai)]). Let 
A 3 ,A 4 = A 2 , where the length of A 3 matches that of 03 - Thus Lemma 

C.31 tells us that k% = ’n(A 4 [ri/dom(A3), 03 /dom(A 3 )]). H't x and k 2 = 

’n(A4[T2/dom(A3), 0 2 /dom(A 3 )]). H't 2 . Thus, we are done, with a = dom(A3), 
z = dom(A 2 ), and k = TIA4. H'~a. □ 

Definition C.61 (Joinability). We say that two types T\ and t 2 are joinable if there 
exists an erased type e such that |_TiJ e I 72 J • 
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Lemma C.62 (Completeness of type reduction). /f E;T bo 7 : T\ K1 ~ K2 t 2 and 
c # 7 for every c :0 e T, then: 

1. There exists some erased type e such that |_TiJ e **~ [ t 2 \. 

2. There exists some erased type e such that |_KiJ ***** e [n 2 \ ■ 

Proof. By induction on the typing derivation. For the purposes of exposition, we 
present the types cases separately from the kinds cases, but in a formal proof, they 
would be interleaved. First, the types cases: 

Case Co_Var: Impossible. 

Case Co_Refl: Choose e = |_TiJ and we are done. 

Case Co_Sym: By induction. 

Case Co Trans: Use the metavariable names from the rule: 


E; r bio 71 : Ti ~ t 2 E; F bo 72 : t 2 ~ t 3 
E; T bo 7i 9 72 : n ~ t 3 


Co _ Trans 


The induction hypothesis gives us <7 such that [uj ' w * ei Lv 2 J - It also 
gives us e 2 such that [r 2 J e 2 L T 3_I- Lemma C.55 gives us e 3 such that 
€1 e 3 e 2 . Thus, e 3 is a common reduct of |_TiJ and |_t 3 J as desired. 

Case Co_ Coherence: We know that [uj = \j 2 \ and thus either can be the 
common reduct. 

Case Co Con: By induction and repeated use of R_Con. 

Case Co_AppRel: By induction and repeated use of R_AppRel. 

Case Co_AppIrrel: By induction and repeated use of R_AppIrrel. 

Case Co_CApp: By induction. 

Case Co_PiTy: By induction. Note that the substitution in the conclusion is 
erased by coercion erasure and so poses no complications. 

Case Co_PlCo: By induction. Note that we need the c # 7 premise of Co_PlCo 
in order to use the induction hypothesis here. Once again, the substitution in 
the conclusion causes no bother. 

Case Co _Case: By induction and R_Case. 

Case Co_Lam: Similar to Co_PiTy, noting that the substitution in the result of 
Co_Lam is erased by coercion erasure and so poses no complications. 

Case Co_CLam: Similar to Co_PlCo. Once again, the premise of c # 7 is 
critical. 

Case Co_Fix: By induction and repeated use of R_Fix. 

Case Co_Absurd: By induction. 
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Case Co_ArgK: The induction hypothesis gives us eo such that \Ila: p K\. a\\ 

e 0 [n a: p K 2 - cr 2 J. By repeated use of Lemma C.56, we see that e 0 = II a: p K 3 . a 3 
such that L«hJ k 3 **~ L^ 2 j and |_0ij cr 3 [djJ- Thus k 3 is a reduct of 

[tfij and |_/v 2 J as desired. 

Case Co_CArgK1: Like previous case. 

Case Co_CArgK2: Like previous case. 

Case Co_ArgKLam: Like case Co_ArgK, but appealing to Lemma C.57. 

Case Co_CArgKLam1: Like previous case. 

Case Co_CArgKLam2: Like previous case. 

Case Co_Res: By induction and Lemma C.56. 

Case Co_ResLam: By induction and Lemma C.57. 

Case Co InstRel: We use the metavariable names from the rule: 


E; T bo 7 : IIa: Re ,«i. <J\ ~ IlfliRei^. cr 2 
E; T bo r} : n Kl ~ K2 T2 
E; T bo 7@?7 : cri[ri/a] ~ cr 2 [r 2 / a] 


Co_InstRel 


The induction hypothesis (along with Lemma C.56) gives us e 0 and £\ such that 
|_(j 1 J e 0 [&i\ and |_TiJ £\ J. Lemma C.52 (with Lemma C.34) 

then tells us that L<ti[ti/oJJ e 0 [ei/a] [£r 2 [r 2 /a]J as desired. 

Case Co InstIrrel: Similar to previous case. 

Case Co_CInst: By induction, Lemma C.56, and Lemma C.59. 

Case Co_InstLamRel: Like case Co_Inst, but appealing to Lemma C.57. 
Case Co_InstLamIrrel: Like previous case. 

Case Co_CInstLam: Like case Co_ClNST, but appealing to Lemma C.57. 
Case Co_NthRel: By induction and Lemma C.53. 

Case Co_NthIrrel: By induction and Lemma C.53. 

Case Co_Left: By induction and Lemma C.58. 

Case Co RightRel: By induction and Lemma C.58. 

Case Co_RightIrrel: By induction and Lemma C.58. 

Case Co_Kind: By induction. 

Case Co_S tep: We now must consider the different step rules: 

Case S_BetaRel: By R_BetaRel. 

Case S_BetaIrrel: By R_BetaIrrel. 

Case S_CBeta: By R_CBeta and Lemma C.59. 
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Case S_Match: By R_Match. 

Case S_Default: By R Default. 

Case S_DefaultCo: By R_ Default. 

Case S_UNROLL: By R_Unroll. 

Case S_Trans: |_7"iJ = \r 2 \ in this case. 

Congruence rules: By induction. 

Case S_KPush: We adopt the metavariable names from the statement of 
the rule: 


E hf c H : a:\ rre \K] A; H' A = A 1 ; A 2 n = |A 2 | 
k = ’riaiin-eiK, A. H' a 
a = , U(A 2 [t/ a][ip/dom(Ai)]). H't 
a' = T1(A 2 [t'/ a][il)'/domtAi)]). H't' 

E; Rel(T) bo rj : a ~ a' 

E; Rel(T) bee t' : a : Re \K 

Vi, 7 i = build_kpush_co((«;)@(nths (res 11 rj))] / ip 1 
Vi, •$[ = cast_kpush_arg(^j; 7 ,) 

H —> k' E alt 

E; T ^ case Ko {H{j} V>) > ryof alt —)■ case KQ i?{r'} 4> of alt 


S_KPush 


The only differences between 77 (the redex) and r 2 (the reduct) are the 
t becoming the r' and the V becoming V , along with the dropped cast 
by 77 . Casting is erased, so losing r] is inconsequential. By the definition 
of cast_kpush_arg, we can see that [cast_kpush_arg('0; 7)] = |j0 J for 
any 7 /;, so |_V ; J — \jl J J • This leaves us only the r, but we can see that 
[rj e (r'J (for some e) by the induction hypothesis. We are done 
by Lemma C.52. 

Other push rules: |_TiJ = [ t 2 \ in these cases. 

We now proceed to the kinds cases. 


Case Co_Var: Impossible. 

Case Co_Refl: Choose e = [^ij and we are done. 

Case Co_Sym: By induction. 

Case Co_Trans: Similar to the Co_Trans case for types, above. 
Case Co_ Coherence: By induction. 

Case Co Con: We adopt the metavariable names from the rule: 


Vi, E; T ko li-~ o\ 

E; T hf y i/pq : E; T by //{<R} : n 2 

E;T bo 


Co_Con 
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We invert E; T by H{a} : K\ and E; T b y H\o'} '■ k 2 - These both can be proved 
only by Ty_Con. The H in both judgments is the same, and so by Lemma 
C.9 and Lemma C.18, we have unique A 1; A 2 , and H' such that Eh t c H \ 
Ai;A 2] H' . We can thus see that = , n(A 2 [a/dom(A 1 )]). H' a and k 2 = 
, n(A 2 [CT / /dom(Ai)]). H'a'. The induction hypothesis gives us e' such that, Vi, 
|_cqj e' [a[\ . Choose e = ’II(LA 2 J [e'/dom(Ai)]). H' e'. We must show 
the following: 

• TI(LA 2 J[L^J/dom(Ai)]). fl 7 [a\ e 

• ’n(LA 2 J[Lh :/ J/dom(A 1 )]). H' [a'\ e 

Both of these follow from Lemma C.52. 

Case Co_AppRel: We adopt the metavariable names from the rule: 


E; T 7l : Ti ~ t 2 
E; r bo y 2 : <j\ ~ cr 2 

E; T by Ti (Ti : Ki E; T by t 2 ct 2 : k 2 
£; r ^ 7i 72 : Ti (Ji ~ t 2 <t 2 


Co_AppRel 


We invert both E; T b y Ti and E: T b y t 2 a 2 : /c 2 . Both must be proved by 

Ty_AppRel. We thus get all of the following: 


• E; T by A : nia: R eiK 3 - 

• E; T by 07 : 

• Kl = K^[<Ti/a] 

• E; T by t 2 : II 2 a:R e i«:5. kq 

• E; T by ■ K 5 

• k 2 = k,q [a 2 /a]. 

The (kind) induction hypothesis gives us e\ such that riia:Rei |_k 3 J • ' w * e i 

n 2 a:R e iL« 5 j. L^J- Lemma C.56 tells us IR = fl 2 and gives us e 3 and e 4 such 
that ei = Ilia:Reie 3 . e 4 . The (type) induction hypothesis also gives us e 2 such 
that [ctiJ e 2 **~ L^J- Choose e = e 4 [e 2 /a]. We must show 
e 4 [e 2 /a] |yh>[ (T 2 /«]J • Lemma C.34 reduces this to [/c 4 J [IriJ/®] ' w * € 4 [e 2 J-a\ * 

L«eJ [[rx 2 J/aj. We are done by two uses of Lemma C.52. 

Case Co_AppIrrel: Similar to previous case. 

Case Co_CApp: Similar to (but easier than—no argument to worry about) previ¬ 
ous case. 

Case Co_PiTy: Immediate. Both kinds are Type. 

Case Co_PlCo: Immediate. Both kinds are Type. 

Case Co_Case: By induction. 
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Case Co_Lam: We adopt the metavariable names from the rule: 


E ; r r \: ki T yp e ~ T yp £ 
E; T, a\pK i ho 7 : ri CTl ~ 0 

E, r ■ CL• by 7y • (Tl 


E;T ho ^a-pV-'l ’■ Xa: p Ki.Ti no^Ki.oi^n a: p n- 


K2 
2 t 2 


E; r, cr.pKi hy T 2 : a 2 _ 

• (^2[a> S ym v /a]) Aa: p K 2 - (r 2 [a > symjj/a]) 


Co_Lam 


The induction hypothesis tells us both that and k 2 are joinable and also that 
<Ti and a 2 are joinable. We are done by R_Pi. 

Case Co_CLam: Similar to previous case, again requiring the c # 7 condition in 
order to use the induction hypothesis. 

Case Co_Fix: We adopt the metavariable names from the rule: 


E; r bo 7 ; Ti ~ r 2 

E; T ht v fix n : «i E; T by fix 77 : K 2 

----—----- Co Fix 

E; T bo fix 7 : fix 77 ~ fixr 2 

Inversion on E; T by fixTi : K\ tells us that E; T by Ti : IT a:R e |/«i. K\. Similarly, 
we can see that E; T by t 2 : n 2 a:R e |K 2 . /v 2 . The induction hypothesis gives us e 0 
such that Lnia: Re |«:i. e 0 **~ UU^Rei^- « 2 _|- Use of Lemma C.56 gives us 

61 such that |_«ij <§1 [#$] and we are done. 

Case Co_Absurd: By induction. 

Case Co ArgK: Here is the rule with all kinds included: 


E; T bo 7 : (Ilayci. <n) Ty P e ^T yP e (n a: ^ 2 . a 2 ) 
E; T bo argk 7 : k 2 T yp e ~Typ e 


Co_ArgK 


Both kinds are Type and so we are done. 

Case Co_CArgK1: Examine the typing rule with kinds included: 

E;T bo 7 : (Hc:(n rQ.ai) Wpe^Type (nc: ( r2 r '). a2 ) ^ 

E; T bo argk x 7 : iq r 2 

The induction hypothesis (with Lemma C.56) gives us our result. 
Case Co_CArgK2: Similar to previous caes. 

Case Co_ArgKLam: Immediate. Both kinds are Type. 

Case Co_CArgKLam1: Similar to case Co_CArgK1. 

Case Co_CArgKLam2: Similar to previous case. 

Case Co_Res: Immediate. Both kinds are Type. 


253 



Case Co_R esLam: Examine the typing rule with kinds included: 


E-Tkol- AAi.n CAl - K1 ~° A2 - K2 AA 2 .r 2 |Ai| = |A 2 | = n 

XI5 r by t~i : E; T ky t 2 : k 2 

E; T ho res n 7 : n T2 

We are done by the induction hypothesis and Lemma C.56. 
Case Co_InstRel: Immediate. Both kinds are Type. 

Case Co_InstIrrel: Immediate. Both kinds are Type. 

Case Co_CInst: Immediate. Both kinds are Type. 

Case Co InstLamRel: Here is the rule with kinds shown: 


Co_ResLam 


XI; T ho 7 : Aa: R eiKi.Ti 
E; T ho V ■ &i K1 ~ K2 cr 2 

E; T ho '■ Ti[<Ji/a] K ski/a], 


1 Aa:ReiK2- T 2 


t[o- 2 /a] r 2 [cr 2 / a] 


Co_InstLamRel 


Our desired result follows from the induction hypothesis and Lemma C.52. 
Case Co_InstLamIrrel: Similar to previous case. 

Case Co CInstLam: Here is the rule with kinds shown: 


E; T ho 7 : . g ! n.c:7i.^_n c: ^ 2 . K2 A c:</. 2 . (r 2 

E; r ho Vi : 0i X; T ho V 2 ■ 02 „ „ T t 

——-—-r-——:— T-j -.j-p—-j——— r Co CInstLam 

E; r ho 7@(?7i, 172 ) : cbfai/c] cr 2 [? 7 2 /c] 

Our desired result follows by the induction hypothesis and Lemma C.59. 

Case Co_NthRel: We adopt metavariable names from the statement of the rule: 


E; r ho 7 : H{k} 0 <T1 ~ <T2 //{*/} 0 
0j = t 0'=cr 

E; T hy t : Ki E: L hy a : « 2 
E; T ho nthj 7 : r K1 ~ K2 cr 


Co_NthRel 


The induction hypothesis gives us e' such that } |_0J e' ’’W L«'J} L0 J • 
Furthermore, we know that the number of 0 is non-zero. The reductions must 
thus be combinations of R_AppRel, R_AppIrrel, and R_CApp, and we 
can thus consider the reduction of prefixes of the original types. Specifically, we 
can deduce j> |_0 O J L r J ' w * €o -ffpypj} L0oJ Y (J \^ where |_0oJ is a prefix of 
0 and 0 O is a prefix of 0 (and r and <7 are as in the statement of the rule). 
Let t 3 = ipQ and t 4 = 0 O - Lemma C.44 (and inversion) tell us that 

E; Rel(r) hy R{k} 0 : 07 and E; Rel(r) h y : cr 2 . By Lemma C.30, there 

must be <r 3 and <74 such that E; Rel(r) by 13 : cr 3 and E; Rel(r) by t 4 : < 74 . Lemma 
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C.60 tells us that cr 3 = a 5 [K/a,ip/z\ and <74 = a 5 [K'/a, ip /~z\ for some <r 5 , a, and 
z. Lemma C.53 tells us that k and k’ are joinable, as are ip and ip . We thus have, 
by Lemma C.52 that <73 and cr 4 are joinable. Inversion on E; Rel(T) by t 3 t : <76 
and E; Rel(T) by t 4 <7 : (77 tell us that cr 3 and cr 4 must have the form IT, a: p K\. cr 8 
and H 2 a: p K 2 . cr 9 , where E; Rel(T) by r : K\ and E; Rel(T) by a : k 2 . By Lemma 
C.56, we can see that the joinability of cr 3 and cr 4 imply the joinability of K\ and 
k 2 , as desired. 

Case Co_NthIrrel: Similar to previous case. 

Case Co_Left: By induction. 

Case Co_RightRel: By induction. 

Case Co_RightIrrel: By induction. 

Case Co_Kind: Immediate, as both kinds are Type. 

Case Co_S tep: With kinds shown, the rule is as follows: 


E; r by t : k; E; T by t' : k; 
E; r b t — >t' 

E; T bo step r : r t' 


Co_Step 


We can see that the desired result is immediate, as both types have the same 
kind k. 


□ 

Definition C.63 (Erased values). An erased value is an erased type e such that there 
exists a value v with |_vj = e. 

Definition C.64 (Consistency over erased types). We overload the notation T\ oc t 2 
to include relating erased types, where the rules are the same except that all types are 
erased. 

Lemma C.65 (Consistency is reflexive), e oc e 

Proof. By induction on the structure of e. □ 

Lemma C.66 (Consistency is symmetric). If T\ oc t 2 , then r 2 oc r 4 . 

Proof. By induction on T\ oc t 2 . □ 

Lemma C.67 (Reduction preserves values). If e 4 e 2 and e 4 is an erased value, 
then e 2 is an erased value. 

Proof. By induction. The induction hypothesis in needed only in the e 4 = Aa:i rre |K. a 
case. □ 
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Lemma C.68 (Consistency of reduction). If e\ c 2 , then €% oc e 2 . 

Proof. If 61 is not an erased value, the result is immediate. We thus assume ei is an 
erased value. By induction over e\ € 2 . 

Case R_Refl: By Lemma C.65. 

Case R_Con: Immediate. 

Case R_ AppRel: Since % is an erased value, it must be Hy ¥ y if. We are done by 
Lemma C.53. 

Case R_AppIrrel: Similar to previous case. 

Case R_CApp: Similar to previous case. 

Case R_Pl: By induction. 

Case R_Case: Impossible. 

Case R_Lam: Immediate. 

Case R_Fix: Impossible. 

Case R_ Absurd: Impossible. 

Case R_BetaRel: Impossible. 

Case R_BetaIrrel: Impossible. 

Case R_CBeta: Impossible. 

Case R_ Match: Impossible. 

Case R_ Default: Impossible. 

Case R_Unroll: Impossible. 

□ 

Lemma C.69 (Consistency of reductions). If e i e 2; then ei oc e 2 . 

Proof. By induction on the length of the reduction chain, appealing to Lemma 
C. 68 . □ 

Lemma C.70 (Il-expansion). If e i is an erased value and e\ 115. t, then there exist 
8' and r' such that e\ = II5'. t' where 8-^8' and t t'. 

Proof. By case analysis on e\ 115. t. □ 

Lemma C.71 (Il-expansions). If e\ is an erased value and e\ 115. r, then there 
exist 8' and t' such that e\ = 115'. t' where 8 8' and t t'. 

Proof. By induction on the length of the reduction chain, using Lemma C.67 to 
establish the value condition and appealing to Lemma C.70. □ 
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Lemma C.72 (Joinable types are consistent). If e i e 3 e 2 , t/ien ei oc e 2 . 

Proof. By induction on the structure of e\. In all cases: If either e± or e 2 is not an 
erased value, the result is immediate. We thus assume both are values. We know (from 
Lemma C.69) that e\ oc e 3 and e 2 oc e 3 and (from Lemma C.67) that e 3 is a value. 

Now, suppose a is not a Il-type or is a II-type over a proposition. We can see 
from inversion on % oc e 3 that e 3 must have the same head. We can further see from 
inversion on e 2 oc e 3 that e 2 must have the same shape, and thus that ei oc e 2 as 
desired. 

Finally, we consider e\ = Ila:^. r. We see (from Lemma C.56) that e 3 = II a: p K r . t' 
with k k' and r t' . Now we can use Lemma C.71 to see that e 2 = Ha: p K". t" 

with k" k' and t" t'. The induction hypothesis tells us r oc t", which gives us 
ei oc e 2 by C_PiTy. □ 

Lemma C.73 (Erasure/consistency). If |_TiJ oc [r 2 J, then T\ oc t 2 . 

Proof. If either T\ or t 2 is not a value, the result is immediate. We thus assume both 
are values. Proceed by induction on the structure of T\. 

Case T\ = a: Impossible. 

Case T\ = H{t} : We have |_TiJ = H{ |_ r j>, and thus |_t 2 J = H{ T '} v- From the defini¬ 
tion of |_t 2 J , we can see that t 2 must be headed by H or be a cast. The latter is 
impossible, as a cast is not a value. Thus t 2 is headed by H and we are done. 
Case T\ = <7i cr 2 : For t\ to be a value, it must be headed by some constant H. Proceed 
as in the previous case. 

Case T\ = II a: p K. r: Similar to case for H{ r }, but also using the induction hypothesis. 
Case t i = II c:(j).T: Similar to case for >>. 

Case Ti = t > 7 : Impossible. 

Case ri = 7 : Impossible. 

Case Ti = case K rof alt: Impossible. 

Case Ti = A 8. a: Similar to case for H^j. 

Case Ti = fixer: Impossible. 

Case Ti = absurd 7 To: Impossible. 

□ 

Lemma C.74 (Consistency). IfT contains only irrelevant type variable bindings and 
£; T h^o 7 : T\ ~ t 2 then Ti oc t 2 . 

Proof. If either r% or t 2 is not a value, then we are done. So, we assume that both 
are values. Lemma C.62 gives us e such that |_ / TiJ 4 L T 2 j- (This lemma is 
applicable because there are no coercion bindings in T.) Lemma C.72 then tell us that 
|_TiJ oc |_t 2 J. Finally, Lemma C.73 gives us T\ oc t 2 as desired. □ 
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C.ll Progress 

Lemma C.75 (Canonical forms). 

1. If E; F by v : 11 ( 5 . k, then v = X6. a. 

2. If E; T hty v : 115. n, then v = H{ T } V’- 

3. If E; r by- p : Ha, then v = H'^y if. 

Proof. By case analysis on the shape of values (along with Lemma C.20). □ 

Lemma C.76 (Value types). //E;T b y v : k, then k is a value. 

Proof. By case analysis on the possible shapes of values. □ 

Lemma C.77 (Type constant parents), //big E ok and E be H : Ap A 2 ] H', then 
E be H' : 0;Rel(A!);Type. 

Proof. By case analysis on E be H : Ap A 2 ; H' □ 

Theorem C.78 (Progress). Assume T has only irrelevant variable bindings. If E;T by 
r : k, then either r is a value v, t is a coerced value v>j, or there exists t' such that 
E;TbT —» t'. 

Proof. By induction on the typing judgment. 

Case Ty_Var: Impossible. 

Case Ty_Con: t is a value. 

Case Ty_AppRel: We adopt the metavariable names from the rule: 


E; r by Ti : Ua-.^Ki. k 2 E; T by t 2 : k 1 

E; T by n t 2 : k 2 [t 2 /a] 


Ty_AppRel 


Use the induction hypothesis on tl, giving us several cases: 


Case Ti = v: We now use Lemma C.75 to give us two cases: 

Case Ti = H{t} Then t = H{t} ifr 2 \sa value and we are done. 

Case Ti = Aa:R e |Ki. a: We are done by S_BetaRel. 

Case Ti = v > 7 : We wish to use S_PushRel but we must prove E; Rel(r) bo 
7 : Ua: Re \K.cr ~ Ua: Re \K,'. a' (for some II, a, k, a, k', and a'). We know 
by inversion that E; T b y v \> 7 : Ua: Re \Ki. k 2 . Further inversion gives 
us E;Rel(r) bo 7 : ^0 ~ IIa:Rei«:i.K 2 and E;T by v : Lemma C.74 

tells us that kq oc IIa:ReiK i. k 2 - Lemma C.76 tells us that kq is a value. 
Inversion on oc na: Re |Ki. k 2 must happen via C_PiTy, telling us that 
Kq = na: Re |K'i. k' 2 for some k\ and k' 2 . We can thus use S_PushRel and 
are done with this case. 
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Case E; T b Pi —> t[: We are done by S_AppRel_Cong. 

Case Ty_AppIrrel: We adopt the metavariable names from the rule: 


E, b by Pi • hi Cl. Irrel ^1 • ^2 E, Rel(P) by P 2 • 

E; T by pi{p 2> : Kfcfa/aj 


Ty_AppIrrel 


Use the induction hypothesis on r%, giving us several cases: 


Case T\ = v: We now use Lemma C .75 to give us two cases, which are han¬ 
dled like the Ty_AppRel case, but using S_BetaIrrel in place of 
S_BetaRel. 

Case Ti = v > 7: As in Ty_AppRel, but using S_PushIrrel. 

Case E; T b Pi —» t[: By S_AppIrrel_Cong. 

Case Ty_CApp: Like previous application cases, but using S_CBeta, S_CPush, 
and S_CApp_Cong. (The S_CPush rule looks a bit different than 
S_PushRel, but the typing premise of that rule has the identical structure as 
the previous case.) 

Case Ty_Pi: Immediate, as all II-types are values. 

Case Ty_Cast: In this case, we know r = tq > 7 . Using the induction hypothesis 
on r 0 gives us several cases: 


Case t 0 = v: v > 7 is a coerced value and so we are done. 

Case t 0 = v > rj: We have t = (v > 77) > 7. We are done by S_Trans. 
Case E; T b Po —» p,',: We are done by Cast_Cong. 

Case Ty_Case: We know here that t = case,,. t 0 of alt. Using the induction 
hypothesis on t 0 gives us several cases: 


Case t 0 = v: We can derive the following: 

• E; T by v : ’IIA. H'a (from a premise of Ty_Case) 

• v = t 0 = Hi [T y ?/; (by Lemma C.75). Note that it does not matter 
whether |A| =0 when using Lemma C.75. 

• E; T by %} -0 : ’nA'. H" r (Lemma C.42) 

• E be H : A.i, A 2 ; H" (same invocation of Lemma C.42) 

• A' = A, H' = H", and t = a (Lemma C.20) 

Since we have E be H : A 1 ;A 2 ;7/ 7 and 

alt are exhaustive and distinct for H', (w.r.t. E), we can conclude 
that either there exists H —>• T\ e alt or there exists _ —>• T\ e alt. In the 
former case, we use S_Match and we are done; in the latter case, we use 
S_ Default. 

Case t 0 = v > 7: We can derive the following: 
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• E; T ht y v > 7 : ’IIA. H'a (from a premise of Ty_Case) 

• E; Rel(r) bo 7 : >7) ~ ’IIA. H'a (inversion of Ty_Cast) 

• E; r ht y v : Ko (same inversion) 

• k 0 oc ’IIA. H'a (Lemma C.74) 

• /c 0 is a value (Lemma C.76) 

• /c 0 = TL$i. /ci (inversion on /c 0 oc ’IIA. H'a) 

• v = H^yip (Lemma C.75) 

• E ht c H : a:| rre |/c; A 2 ; H" (Lemma C.42) 

• E;T H^y.tjf : Tl(A 4 [7/dom(A 3 )]). iPr where A 3 ,A 4 = A 2 [r/tt( 
(same invocation of Lemma C.42) 

• /c 0 = , n(A 4 ['0/dom(A3)]). H"t (Lemma C.20) 

• H" = H' and |A| = |A 4 | (repeated inversion on /c 0 oc ’IIA. H'a) 
There are now two possibilities: either H —>• ao E alt or there is a default 
case that matches. In the latter case, we are done by S_DefaultCo. We 
thus assume the former. 

• E; I': ’IIA. H'a h^ -7 H —>• cr 0 : k (a premise of Ty_Case) 

• From the premises of Alt_Match: 

- Ao,A 4 = A 2 [a/a] 

- dom(Ai) = dom(A) 

- match{ dom (A 0 )}(types(A 1 ); types(A)) = Just (^ /dom(A 0 )) (also us¬ 
ing Property C.13) 

• | A 4 1 = | A| (from the fact that their domains are the same) 

• | Ai| = |A 4 | (transitivity of =) 

• dom(A 0 ) = dom(A 3 ) (from the definitions of A 0 , Ai, A 3 , and A 4 and 
the fact that |Ai| = |A 4 |) 

• Let n = | Ai| and A 5 be the suffix of A 2 of length n. 

• A = A 5 [a/a]['07dom(A o )] (Property C. 14) 

• E; Rel(r) bo 7 : , n(A 5 [r/a][Vf/dom(A 0 )]). H't 

^{(A^a/a]^/dom(A 0 )]). H'a (substitution in the kind of 7 as 
stated above) 

• E; Rel(r) by H'a : Type (premise of Ty_Case) 

• E be H' : 0; a:Rei/c; Type (Lemma C.77) 

• E; Rel(r) bee ^ : a: Re \K (Lemma C.42 with Lemma C.18) 

We have now proved the premises of S_KPush and so stepping is possible. 
We are done with this case. 

Case E; T b t 0 —> Tq: We are done by S_Case_Cong. 

Case Ty_Lam: We know that r = A 8. tq. If 8 is anything but an irrelevant-type- 
variable binder, we are done. So we assume that we have r = Aa:| rre |/c 0 . r 0 . Using 
the induction hypothesis on r 0 gives us several cases: 

Case t 0 = v: We are done, as Aa:| rre |/c 0 . v is a value. 
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Case To = v > 7 : We are done by S_APush. 

Case E; T, a:| rre i «: 0 b r 0 —> t' q : We are done by S_IrrelAbs_Cong. 

Case Ty_Fix: We know that r = fix To- Using the induction hypothesis on To 
gives us several cases: 

Case To = v: We know E;T by v : na:R e |R. k. Lemma C.75 tells us v — 
AaiReiR. <t 0 and we are done by S_Unroll. 

Case To = v > 7 : We can derive the following facts: 

• E; T by v > 7 : IIa:ReiR. k (premise of Ty_Fix) 

• E; Rel(r) bo 7 : ~ na:R e |R. k (inversion on Ty_Cast) 

• E; r by v ■ Ko (same inversion) 

• k 0 ex. rja: Re |/T. k (Lemma C.74) 

• r 0 is a value (Lemma C.76) 

• r 0 = fJa:ReiRi.R 2 (inversion on C_PiTy) 

• v = Xa:R e \Ki.a (Lemma C.75) 

We are done by S_FPush. 

Case E; T b To —> t' q : We are done by S_Fix_Cong. 

Case Ty_Absurd: We know here that t = absurd 7 To where E; Rel(r) bo 7 : 

ip! ~ H 2{ , 2} ip 2 . By Lemma C.74, we also know that -0i oc H 2 {t 2 } " 02 - 
Both of these types are values, so this could only be by C_TyCon, but that 
rule requires Hi = H 2 , which is a contradiction. This case cannot happen. 


□ 


C.12 Type erasure 

The type erasure operation e — KJJ is defined in Figure 5.19 on page 131. 

Definition C.79 (Expression values). Let values w be defined by the following sub¬ 
grammar of e: 

w ::= H y \ U\ A a.e \ A».e 

Lemma C.80 (Expression substitution). [[r[cr/a]JJ = J|TjJ[|_cr|/a] 

Proof. By induction on the structure of T. □ 

Lemma C.81 (Irrelevant expression substitution). If T,:T h v t : k and a:\ rre \n' e T, 
then HT[<7/a]]| = \\r^. 

Proof. By induction on the typing derivation. 
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Case Ty Var: Here is the rule: 


E h 5 tx T ok a:R e |ft £ r 
E; T hty a : k 


Ty_Var 


We see that r ^ a, because the rule would require a to be relevant. Thus r = b 
(for some b ^ a) and thus the substitution causes no change. 

Case Ty_Con: Immediate from the definition of []_•]]. 

Case Ty_AppRel: By induction. 

Case Ty_ AppIrrel: By induction. Note that we do not need to use the induction 
hypothesis on the argument; we would not be able to because of the use of the 
Rel(T) context. 

Case Ty_CApp: By induction, not looking at the coercion. 

Case Ty_Pi: Immediate from the definition of [[•]]. 

Case Ty_Cast: By induction, not looking at the coercion. 

Case Ty_Case: By induction, not looking at the kind. 

Case Ty_Lam: By induction, not looking at the classifier of the binder. 

Case Ty_Fix: By induction. 

Case Ty_ Absurd: Immediate from the definition of [[•]]. 


□ 

Lemma C.82 (Expression substitution of coercions), J|r[ 7 /c]JJ = [[rJJ 

Proof. By induction on the structure of r. □ 

Theorem C.83 (Type erasure). //E;T 1 5 t — >■ t' , then either [|_t[] — > [[r'JJ or 

bn = i§- 

Proof. By induction on E; T hr —> t' . 


Case S_BetaRel: By E_Beta and Lemma C.80. 

Case S_BetaIrrel: Both expressions are equal by Lemma C.81. 
Case S_CBeta: By E_CBeta and Lemma C.82. 

Case S_Match: By E_Match. 

Case S_Default: By E_Default. 

Case S_DefaultCo: By E_Default. 

Case S_ Unroll: By E_Unroll. 

Case S_Trans: Both expressions are equal by the definition of 
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Case S_IrrelAbs_Cong: By the induction hypothesis. 

Case S_App_Cong: By the induction hypothesis and E_App_Cong. 

Case S_Cast_Cong: By the induction hypothesis. 

Case S_Case_Cong: By the induction hypothesis and E_Case_Cong. 

Case S_Fix_Cong: By the induction hypothesis and E_Fix_Cong. 

Push rules: Both expressions are equal by the definition of [[•]]. 

□ 

Lemma C.84 (Expression redexes). If [[rJJ is not an expression value, then r is 
neither a value nor a coerced value. 

Proof. By induction on the structure of r. 

Case t = a: Immediate. 

Case t = H{t\: Impossible. 

Case r = r 0 '0o : We have two cases here: 

Case T\ = if: Impossible, as [[r]J is an expression value. 

Otherwise: Immediate, as r is neither a value nor a coerced value. 

Case t = 11(5. To: Impossible. 

Case r = t 0 > 7 : Since [jr 0 > 7 ]] is not an expression value, we know that [[t 0 JJ is 
not an expression value, because these expressions are the same. We thus use 
the induction hypothesis to discover that t 0 is not a value or a coerced value. 
We thus know that t 0 > 7 is not a coerced value (and is obviously not a value). 
Case t = case K T 0 of alt: Immediate. 

Case t = AaiRei^o - t 0 : Impossible. 

Case t = Aa:| rre |Ko- t 0 : We have two cases: 

Case [[toJJ is an expression value: In this case [J_Aa:| rre i/To- tq]J is also an ex¬ 
pression value, a contradiction. 

Case [[toJJ is not an expression value: By induction, To is neither a value 
nor a coerced value. Thus, t = Aa:i rre |K 0 - To must also not be a value. (It is 
clearly not a coerced value.) 

Case t = Xc:0. t 0 : Impossible. 

Case t = fixT 0 : Immediate. 

Case t = absurd 7 a: Impossible. 

□ 
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Lemma C.85 (Expression values do not step). There is no e' such that w —> e!. 

Proof. Straightforward case analysis onw. □ 

Theorem C.86 (Types do not prevent evaluation). Suppose E;T by r : k and T 
has only irrelevant variable bindings. If J_rJJ —> e', then E; T b r —> r' and either 

M = <■ ° r M - JH- 

Proof. We know that [|r]j is not an expression value via the contrapositive of Lemma 
C.85. We thus know that r is neither a value nor a coerced value by Lemma C.84. 
We can now use Theorem C.78 to get r' such that E; T h r —> t'. Finally, we use 
Theorem C.83 to see that jjr']] — e ' or [b"']] — [[ r JJ as desired. □ 

Remark. Note in the statement of Theorem C.86 that the context T must have only 
irrelevant variable bindings. This means that the expression [frjj is closed, as one 
would expect of a program that we wish to evaluate. 


C. 13 Congruence 

Definition C.87 (Unrestricted coercion variables). Define a new judgment 1 ^ 0 to be 
identical to bo; except with the c 7 premises removed from rules Co_PlCo and 
Co_CLam and all recursive uses o/bo replaced with i| 0 . 

Remark. It is not necessary to introduce a judgment that uses ly Q . Thus, for example, 
the Co_Refl rule of ly Q has a by premise that may contain proofs of bo- 

Lemma C.88 (Subsumption of coercion typing). 7/E; T bo 7 : (f>, then E; T hj : 0 7 : (j). 

Proof. Straightforward induction. □ 

Lemma C.89 (Unrestricted proposition regularity). If E; T b 0 7 : 4>, then E; T brop 
(j) ok. 

Proof. Identical to the proof for Lemma C.44. □ 

Theorem C.90 ((Almost) Congruence). If E; Rel(T) bo 7 : &i K ~ K 02 and 
E; T, a: p K, U by t : k 0 where none ofr, k g , k and the types in T and T' bind any coercion 
variables, then there exists r) such that E; Rel(r, T'[cr\/a]) b 0 V : t[<j\/ a] 
r[a 2 /a\. 

Proof. By induction on the size of the derivation of E; T, a: p K,T' by T '■ ^ 0 , using 
Lemma C .88 frequently to convert between the coercion typing relations. 

Case Ty_Var: Here r = b. We have several cases: 

Case b E dom(T): By Lemma C.12, a # k 0 . We are done, choosing p = (b). 
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Case b = a: By Lemma C.12, a # kq. We are done, choosing 77 — 7 . 

Case b e dom(r / ): We know T' = Tx, 6:R e |7c 0 , T 2 . Lemma C.9 and Lemma 
C.7 give us E; Rel(T, a: p K, T 4 ) by k 0 : Type with a derivation smaller 
than that with which we started. Use the induction hypothesis to get 
£; Rel(r, ri[< 7 i/a]) bo 770 : K 0 [ai/a[ ~ K, 0 [a%/(i. Choose 77 = b ~ Vo b > 770 
and we are done. 

Case Ty Con: By Lemma C.29, repeated use of the induction hypothesis, Lemma 
C.35, and Co_Con. 

Case Ty_AppRel: By the induction hypothesis, Lemma C. 35 , and Co_AppRel. 

Case Ty_AppIrrel: By the induction hypothesis, Lemma C.35, and 
Co_AppIrrel. 

Case Ty_CApp: We adopt the metavariable names from the rule (changing the 
name of the coercion used to 7 '): 


E; T hty t : Uc:cj). k E; Rel(r) bo 7 : </> 
E;T ht y T7 : k[~//c\ 


Ty_CApp 


The induction hypothesis gives us 771 such that E; Rel(T, T'[<Jifa]) ly 0 771 : 
r[<7i/a] ~ r[cr 2 /o]. Choose 77 = 771 (7 / [cri/a],7 / [cr 2 /o]). We are done by Lemma 
C .35 and Co_CApp. 

Case Ty_Pi: We have several cases, depending on the shape of the binder: 


Type variable binder: In this case, we know that r = Ub: p 'Ki.T 0 
and k 0 = Type. The induction hypothesis gives us 771 such that 
E; Rel(T, T'[<j\/a]), b\^\K\[cr\/a] h ^ 0 771 : r 0 [(Ji/a] ~ T 0 [cr 2 /a]. We can also 
use Lemma C.9 and Lemma C.7 to see that E; Rel(r, a: p K, T') by K\ : Type, 
with a smaller derivation height than E;T, a: p K,T' by Hb: p >K\. tq : Type. 
We can thus use the induction hypothesis again to get r / 2 such that 
E; Rebrijr'^i/o-]) h| 0 77 2 : /^[01/a] ~ Ki[a 2 /a\. Choose 77 = (II&: p / 77 2 . 771)9773, 
where 


• V3 = a 3 ~(Type> &4 

• a 3 = Ub:p>Ki[( 72 /a]. (T 0 [a 2 /a][b > symrj 2 /b]) 

• a 4 = II 6 : p /Ki[(j 2 /a].To[cr 2 /a] 

We must show E; Rel(T, r'[<Ti/aj| 1 | 0 77 : (Ilb: p 'K\. r 0 )[cri/a} ~ 

(II b-.piKi. t 0 )[(j 2 /a]. We will do this by proving both of these: 

E; Rel(L. V'[<j\/a]) i | 0 Ub\pir} 2 .r}x : (U.b\p/Ki[<Ji/a]. T 0 [< 7 i/a]) ~ cr 3 This is 
straightforward from Co_PiTy. 

E; Rel(T, T'[<j 4 /a\) 1 ^ 0 cr 3 ~(T yP e> cr 4 : <j 3 ~ cr 4 We must prove that both the 
left-hand type and right-hand type have kind Type. The left-hand re¬ 
sult comes from Lemma C.89 on the result of the previous branch 
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of this list of things to prove. The right-hand result conies from 
Lemma C .44 on our assumption about 7 and Lemma C .35 (us¬ 
ing Lemma C.6 in the p = Irrel case). Now we must prove that 
the erasure of the two types equal, which boils down to proving 
\jo[o2/a\[b > sym 772/6]] = boD^/a]]- By Lemma C. 34 , the LHS be¬ 
comes Ltp[ct 2 /a]J [L6 > sym77 2 J/6]. We can see that [b > symr^J = b 
and thus the two sides of the equation are equal. 

Coercion variable binder: In this case, we know that r = To 

and k 0 = Type. The induction hypothesis gives us 771 such that 
S; Rel(T, r'[cTi/a]), c: 0 [(Ji/a] !j: 0 771 : T 0 [<7i/a] ~ To fa /«]• Let (j) = 
K\ k i~ k 2 ^ 2 . We can also use Lemma C. 9 , Lemma C.8, and inver¬ 
sion on Prop_Equality to see that E; Rel(T, a: p K, T') by k 4 : k\ and 
E; Rel(T, a: p K, T') by ft2 : ft 2 , both with a smaller derivation height than 
E; T, a: p K, L' by II c:cj). t 0 : Type. We can thus use the induction hypothesis 
again to get 772 and 773 such that E; Rel(T, T'[<Jx/a\) 1 | 0 772 : fti[cri/a] ~ 
Kifa/d\ and E; Rel(T, T'[cri/a]) 1 ^ 0 773 : K 2 [(J\/a\ ~ n 2 fa/a]. Choose 
77 = (lie:(772,773). 771) 9 774, where 

• 774 = CT 3 ~(Type) &4 

• 0-3 = Uc:(f>[a 2 /a\. (t 0 [cr 2 /a][775/c]) 

• (74 = nc:0[<7 2 /a].T O [<72/a] 

• Vb = 772? C^sym773 

We must show E; Rel(t\T'[< 7 i/a]) V '■ (IIc: 0 . T 0 )[(7i/a] ~ (IIc: 0 . To)[(7 2 /a]. 
We will do this by proving both of these: 

E; Rel(T, T'bq/a]) b 0 Be:(772,773). 771 : (Uc:(/)fa/ a]. T 0 [(7i/a]) ~ a 3 This is 
straightforward from Co_PlCo. Note that we cannot guarantee the 
c # 771 condition here, necessitating the use of ly 0 instead of bo- 
E; Rel(T, Y'[a\/a}) ly 0 cr 3 ~(T yP e> cr 4 : a 3 ~ cr 4 We must prove that both the 
left-hand type and right-hand type have kind Type. The left-hand 
result comes from Lemma C .89 on the result of the previous branch of 
this list of things to prove. The right-hand result comes from Lemma 
C .44 on our assumption about 7 and Lemma C .35 (using Lemma C.6 
in the p = Irrel case). Now we must prove that the erasure of the two 
types equal, which boils down to proving [to[<t 2 /a] [775/c]J = Lto [ct 2 /«] J • 
This holds by Lemma C. 59 . 

Case Ty_Cast: We adopt the metavariable names from the rule (but renaming 
the coercion used in the cast to 7'): 

E; Rel(r) bo 7 : fti ~ ft2 

E;Tby r : Ki E; Rel(T) by ft2 : Type ^ 

E; T by r > 7 : k 2 ~ 
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The induction hypothesis gives us rft such that E; Rel(T, T^cti/ a]) ly 0 rft : 
T[(7i/a] K d^iAU«iK/a] r[a 2 /a]. Let rj 2 = ((r[<Ti/o] > a]) « sym f(^] 

r[cri/a]) and rj 3 = (t[cf 2 /a\ ~y[ CT2 / a ] (r^M > y[cr 2 /o])). It is easy to see 
(using Lemma C.89 and Lemma C.35) that 772 and rj 3 are well-typed. Choose 
77 = r /2 9 T)\ 9 r/ 3 , and we are done. 

Case Ty_Case: By repeated use of the induction hypothesis, Lemma C.35, and 
Co_Case. 

Case Ty_Lam: Like the case for Ty_Pi. 

Case Ty_Fix: By the induction hypothesis, Lemma C.35, and Co_Flx. 

Case Ty_Absurd: We adopt the metavariable names from the rule (but renaming 
the coercion used to 7 '): 


E; Rel(r) 7 : H l{Tl} ^ - H 2{Y2} H x ^ H 2 

E; Rel(r) hf y r : Type 

E; r hfy absurd 7 r : t 


Absurd 


The induction hypothesis gives us 771 such that E; Rel(T, T^ui/a]) l^ 0 771 
T[cri/a] ~ r\a 2 ja\. Choose 77 = absurd ( 7 ' [a x / a], 7 ' [a 2 / a]) 771. We know 7 ' [cr*/a] 
(for i e { 1 , 2 }) is well-typed by Lemma C. 35 . We are thus done. 
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Appendix D 

Type inference rules, in full 


D.l Closing substitution validity 

| E; r Ijubst 0 : A | u 9 substitutes the variables in A away.” 

——--- Subst Nil 

£; T ^ ubst 9:0 


E; T hf y a[9] : k 


S; T bubst 9 

: A[0|«] 

fi ubst 9 : 

a: Re |R, A 

E; Rel(r) 

a[9] : k 

S; T bubst 9 : 


fi ubst 9 : a: hre] K, A 

E; Rel(r) 

h^o c\9\ : (f) 

S; r fi ubst 



E; r hg ubst 9 : c:< 4 ), A 


Subst_TyRel 


Subst_TyIrrel 


Subst_ Co 


D.2 Additions to Pico judgments 


E; \ l / t : k\ Extra rule to support unification variables in types 


a: ReiVA.RG'h E^ tx ^ok 

E; ^ ec ^ : A 

E; 'I' ol^ : K[^/dom(A)] 
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E; 7 : q 


Extra rule to support unification variables in coercions 


l : V A .(f) e E ^ tx \l/ ok 

E; Nec ip ■ A 

E;tt^:<^/d 0 m(A)] 


Co UVar 


E b tx d/ ok Extra rules to support binding unification variables 
E; Rel(\l/, A) hjjy k : Type E f| tx \l/ ok 


E t^ tx $,a: p VA./{ ok 

E; Rel(^>, A) t^rop 0 ok E ^ tx \l/ok 
E fe x V,l : V A.0 ok 


Ctx UTyVar 


Ctx UCoVar 


D.3 Zonker validity 

I E; \l/ ^ © : fl I “0 zonks all the unification variables in fh” 


E;^ ^ 0 : 0 


Zonk_Nil 


E; \l/, A hfy r : k 

E;^ ^ © : 0[Vdom(A). r/a] 

E;^ ^ Vdom(A).r/a,0 : a: Re ,VA.«,fi 


Zonk_TyVarRel 


E;Rel(tf,A) tf y r : k 
E;^ 0 : fl[Vdom(A).T/a] 

E; \l/ t= Vdom(A).r/a, © : a :| rre | V A./c, fl 


Zonk_TyVarIrrel 


E; A t ^ 0 7 : 0 

E;tf t* 0 : n[Vdom(A). 7 /t] 

E; ^ Vdom(A). 7 /t, 0 : t : V A.</>, fi 


Zonk_CoVar 


D.4 Synthesis 

|E;d f l^t~^T:RHfl Synthesize a type with no invisible binders. 



E^tAt-wriftHfii 

if * c k k ' h n 2 

-=- ITy Inst 

E; T t r -0 : k' H fi x , fi 2 

: k H Synthesize a type, perhaps with specified binders. 


a- Rei/c e T 






E; T ti T\ : Ko H 
ten k o; Rel 7; II; a; p; Kq; k 2 H ^2 

E; T, fti, fi 2 ; P f, t 2 : /ci ^2; t 2 H 0 3 
E; vp |A ti t 2 (n > 7) -02 : ^2[t 2 /a] H ^1, fi 2 , 0 3 


E; ^ |A ti -w n : n S pe C a:p/Ci. n 2 H 
E; T, Qi; p |A g t 2 : Ki -w V> 2 ; r 2 H fi 2 
E; T |A ti @t 2 Ti fa ■ k 2 [t 2 /o\ H fii,0 2 


ITy AppSpec 


E;Rel(^) tes^adn! 

E; T, t : a r H tt 2 
E; T (t:: s) r : a H 0 i, 0 2 


ITy_Annot 


E; T te to t 0 : R 0 H tt 0 

E; T, Q 0 terut alt; k 0 7; A; H'\ r H fig 

fresher Q' = fi 0 , n' 0 , CE| rre |Type 

Vi, E; T, f2'; ’IIA. H' r; t 0 > 7 lift alt* : a alti H 

alt = make exhaustive(a/f; /c) 

- ---——- ,-- ITy_Case 

E; T (A case t 0 of alt case a (t 0 > 7) of alt :aH £T, Vl 


E; T tefivar a : K\\ v H fi x 
E; T, fii, aiRei^i 1 ^ t r : k 2 H Q 2 

E;T (A Aqvar.t Aa: Re |/ci. (t[£]) : II^aiReiRi. (k 2 [£]) ^ ^i,^ 2 


ITy_Lam 


E; T tefivar ^ a : k 

E; T, Q x , a:i rre |Ki ^ t t : r 2 H Q 2 

_ ^2 a:|rrel^l ^2? £ _ 

E; \I/ (A Aqvar. t Aa:| rre |Ri. (t[£]) : n^aiReifiq. («2[£]l) ^ ^1, 0 2 


ITy_LamIrrel 
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ITy_Arrow 


E; \I/ fe ti : Type •w ri H fii 
E; \l/ fe t 2 : Type -»r 2 Hfi 2 

_ a # r 2 _ 

E; 'I' lj ti -»• t 2 n Req a: R eiTi. t 2 : Type H fii, 


E; fe ti : Type •w ri H Oj 
E; 'I' fe t 2 : Type r 2 H Jl 2 

_ « # t 2 _ 

E; 'k % ti '->■ t 2 -w TI Req a: Re iri. t 2 : Type H fii, Q 2 


ITy_ MArrow 


E;$l^t^r : fvHOi 

k; Rel 7; II; a; Rel; K7; /c 2 H Jl 2 
E; Rel(\&, Qi, Q 2 ) ^r y k 2 : Type 
fresh 1 Q = Oi,fi 2 , £:k 2 ~ /ci 

E; \& I** fixt fix (r > (7 9 na: Re i(/Ci). t)) : Ki H 


ITy_Fix 


E; ti Ti : /ci H O 

E; Q, x: Re |Ki t 2 t 2 : k 2 H I) 2 

Jl 2 X:R e |Ki fl' 2 ;£ 

E;^ § let x t t int 2 (Ax: Re iKi. (t 2 [^]))ti : K 2 [^I[ri/a| H ^,0 2 


D.5 Checking 


E;\frfet:/c~>T-lf)| Check against a type with no invisible binders. 

E; ^ fe t 0 7 o_: H 

E; \l/, Q 0 fe rut alt; k 0 7; A; H'\ r H n' 0 

Vi, E; \l/, fi'; ’IIA. H' r; To > 7 fete alt* : /c alti H Qj 
alt = make exhaustive(a/h n) 

-^——- ,- = ITyC_Case 

E; \& fe case t 0 of alt : k case K (r 0 > 7) of alt H Q 1 , fl 
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fen /c; Re I 7 ; II; a; Rel; aci; ao 2 H ^0 
“■(a # k 2 ) 

E; Rel(tf) fe s 4 H Qi 

Q = Q 0 , ^ 1 , ~ Kj 

E; \I/,Q, ftiReiK^ 1^ t : Ki[b > symt/a] 

^2 ^ ^Rel^i ft' 2 ; £ 

V = K 2 [(a > l) > sym l/ a] ~( TyP e> ^2 
r 0 = (Aa: Re |Ki. (t[£][c > t/ 6 ] > 17 )) > sym 7 
E; \P fe A(a :: s). t : k To H £1, Q! 2 


fen «; Rel 7; n; a; Rel; «i; k 2 H O 0 
E; \& fe, aqvar : Aq b : a^; x.ti H f2i 
E; Q 0 , b: Re \ti\ |t:K 2 ^rHfi 2 

^2 ^ ^ : Rei^i ^ 2 ; £ 

E; 'I' fe Aaqvar. t : ac (Aa:R e |Aq. T[^][Ti[a/x]/6]) > sym 7 H 


ITyC_Lam 


fe n ac; Irrel 7; ]J; a; Irrel; K\, k 2 H fi 0 

~'{ a if k 2 ) 

E;Rel(^)fes'w<Hn 1 

Q = £l 0 , ^ 1 , a:aci ~ ac'i 

E; ^/,^, ^iirreiAc'x 1^ t : Av 2 [& > symt/a] -w r H fi 2 

n 2 ^ ^• Irrel' w ^2) £ 

77 = AC 2 [(a > a) > sym if a] ~( T y P e) «2 
To = (Aa:i rre iACi. (t[£][cj > t/6] > 77)) > sym7 
E; \P fe A(a :: s). t : n t 0 -\ fl, Q ' 2 


ITyC_LamIrrelDep 


fen k : Irrel 7; 5 ; a; Irrel; Ki; ac 2 H Q 0 
E; \& fe| aqvar : Ki ^ b : k\] x.T\ H fix 
E; Q 0 , ^1, &• Irrel^ t : K 2 ^ T H 0 2 
f^2 ^ lrrel/^1 ^ 2 ! £ 
t 0 = (Aa:| rre |ACi.T[^][Ti[a/x]/6]) > symq 
E; Ife Aaqvar. t : ac t 0 H O 0 , Hi, Q' 2 


ITyC _ L amIrrel 


E; \& fe t : n Req a:ReiAi;. a;-^tH(] 
E; \& fe fixt : k fixT H f) 


ITyC_Fix 
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E; ^ 1 ^ t t : Ki H 
fjjfe 2 A) K21 T 2 

Q 1 —> A Q 1 ] 

K l[£l] A 1^2 ' w T 2 ^ ^2 

O2 1 ^ A ' v '* ^2 

E; ^ t : k 2 r 2 (AA. t 2 [£ 2 ] t[£l]) H Q', 0' 2 


ITyC_Infer 


E;f |t:«:^rHQ Check against a type that may have specified binders. 


~>(a ^ n 2 ) 

E; Rel(tf) s < H Qi 

ff = f7i, l:k\ ~ k[ 

E; \I/, Q, friReifti t : K 2 [b > sym l /a] r H 0 2 

^2 &:Rei«i ^ 2 ;^ 

?7 = K 2 [(a > /,) > syiru/a] ~(T ype ) «2 

Tq = AfliReiK!. (T[£][a>fc/6] >77) _ 

E; ^ A@(a :: s). t : ns pec a:Rei«i- «2 A) d f^ 2 


ITyC_LamInvisDep 


E; fit, aqvar : Ki b : k[] x.t\ H Qi 
E; \l/, fb, friReifti 1 ^ t : /v 2 ^ r H 0 2 

n 2 ^ ^ : Rei^i ' w ^ 2 ! £ 

To = Aa: Re |«i.T[^][Ti[a/x]/ 6 ] 

E; ^ A@aqvar. t : ns pec a:Rei^i- ^2 To d ^1, ^2 


ITyC_LamInvis 


_l ( a # k 2 ) 

E;Rel(^)^ t S'w<Hni 

f7 = fb, t:/Ci ~ 

E;^,n, 6:i rre iKi t : k 2 [6 > synu/a] r d fl 2 

Q 2 6:|rrel^l ^ 2 ', £ 

77 = /c 2 [(a > t)> synu/a] ~(T ype ) n 2 

T 0 = Ao:i rre |/ci. (t[£][q > t/b] > 77) _ 

E; ^ A@(a :: s). t : n Sp e C a:irrei^i- ^2 w t 0 d ^' 2 


ITyC _ LamInvisIrrelDep 


E; ^ aqvar : Kq 6 : k[-, x.Ti d fii 
E; \l/, Qi, ftllrrel^i |t:K 2 ^rHfi2 

f^2 c— t & - Irrel ' v '* ^2> £ 

T 0 = Aa:i rre i«i.T[f][Ti[a/x]/&] 

E; \I/ A@aqvar. t : n Sp e C a:irrei^i- ^2 t 0 d 0 'i* ^2 


ITyC _ LamInvisIrrel 
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ITyC_Let 


E; \I/ ti Ti : Ki H Q 
E; x: Re |Ki l§ t 2 : k t 2 H 0 2 

f^2 ^ 2- : Rel^l £1 2 ;£ 

E; \I/ let x := ti int 2 • k (Ax:R e iKq. (t 2 [£])) T\ H 0 2 


v < Spec 

E; \I/, $a: p Ki 11 : /{ 2 r H Q 

O c —>• SctipKi £ 

E; ^ t : U u $a: p Ki. k 2 \%a: p Ki. t[£] H 


ITyC_Skol 


E;^ ^ s 


t— in 


E;\I/l^>t:K~'»THf) 


ITyC _ Otherwise 


Check a poly-type (which always has type Type). 


fpt quant II; p 
E; \l/ l^qvar a : k; v H Q 
E; \l/, Q, a: p K ^ s -w tr H 
f^2 ^ CL'. p K ^2) £ 

E; 'k Vqvar. s U v a: p K. (cr[£j) H Q, fi 2 


IPtC_Pi 


E; \P hj^ t : Type r H fii 
E; \l/, Sli, SaiRgiT s ex H 0 2 

f ^2 ^ $«:Re| 7 " ^2;^ 

E; 'k t =>■ s IIinfSaiReiT. (cr[£]) H fii, Q! 2 


IPtC _ Constrained 


E; 'k t : Type -w r H 
E;f 


IPtC_Mono 


D.6 Inference for auxiliary syntactic elements 

I E; 'k; p H^ g t : k ip; r H fl\ Check a function argument against its known type. 


E;^;Rel^ rg t: ^r;rHl] 


IArg_Rel 


E;Rel(f)|t:^rHO 
E; \l/; Irrel f^ g t : k {t}; t H 


IArg_Irrel 
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E; tl/; /cp; t 0 hjt t alt : k alt H O | Synth, a case alt. against a unification variable. 


'Eke H : Ai; A 2 ; H' A 3 , A 4 = A 2 [r/dom(A 1 )] 
dom(A 3 ) — jf dom(A 4 ) = dom(A') 
match {dom( A 3)} (types( A 4 ); types( A')) = Just# 

E; \l/, A 3 t : k r H Q 
Q -4 A 3 -w Q'; £ 

A 3 = A 3 , c:t 0 ~ H( r } X 

E; ; TIA'. 't; t 0 U H x -4 t : « -w if -4 AA' 3 . (t[£]) H Q' 


IAlt_Con 


E; \1/ t: -7—IQ 

E; \l>; k 0 ; r 0 life _ -4 t : k _ —* r H Q 


IAlt Default 


E; \U; k 0 ; t 0 littc alt : /c alt HO Check a case alt. against a known result type. 


E hf c H : A 4 ; A 2 ; H' A 3 , A 4 = A 2 [r/dom(A 1 )] 
dom(A 3 ) = x dom(A 4 ) = dom(A / ) 
match {dom( A 3)} (types( A 4 ); types( A')) = Just# 0 
A'j = A 3 , c:t 0 ~ H {n x 
E; \k, A 3 1^ t : k t H Q 

O 4 A 3 ■W Q'; f 

E; TIA'. ^i tc Hx -4 t : « H -4 AA' 3 . (r[f]) H Q' 


IAltC_Con 


E;^/httt:K~^THQ 


S; vk; k 0 ;t 0 liftc 


IAltC 


E; \l/ l^qvar ^a:/{;i/HO 


4t:/«'^_4rHO 

Synthesize a bound variable. 


Default 


E; l^q aqvar a : k H Q 
E; \k l^aqvar a : k; Req H Q 


IQVar_Req 


E; d' iy q aqvar 


E; tit, aqvar a : n H Q 
E; \l/ l^@aqvar a : /c; Spec H Q 


IQVar_Spec 


a : r H flj Synthesize a bound variable (w/o vis. marker). 


fresh /? 

E;^,a^fl:^H /h| rre ,Type 


IAQVar_Var 


E; Rel(^) I^S4ff HO 
E;$^ q (a::s)^a:(7H0 


IAQVar_Annot 
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| E; ^ ^ aqvar : k a : k!) x.t H 17 | Check a bound variable (w/o vis. marker). 

——-— IAQVarC Var 

E; \ l / te, a : k a : k; x.x H 0 


E; Rel(\k) 

K < a ^ T -\ 0.2 


E; \& te, (a :: s) : k a : <r; x.tx H fii , fl 2 
1 quant II; p I Interpret a quantifier. 


IAQVarC _Annot 


bV^h; Irrel 


IQu_ForAll 


b'Vw TI; Irrel 


IQu_MForAll 


te n n ; Re i 


iQu_Pi 


b'n ’n; Rel 


IQu_MPi 


D.7 Kind conversions 

| fan R; Pi ^ 7 ; II; a; p 2 ; Kg; r 2 H fl | Extract out the parts of a function kind. 


fen n Req a:pRi. r 2 ; p 0 (U Req a: p Ki. k 2 ); II; a; p; k 2 H 0 


fresh l fresh/?i,/? 2 

fl = )0i:i rre |Type,^ 2 :| rre |Type,t:«o ~ n Req a: p /3i. fi 2 
ten «o; P II; a; p; /?i; ^ 2 H fl 


IFun_Cast 


E; ^ temt alt; k^7;A;H; : 


Extract out the parts of a scrutinee’s kind. 


E;Rel(tf) Hr: Type 

S; terut St;TIA.tf r-w (TIA.tf r); A; tf;rH 0 


IScrut_Id 
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IScrut_Cast 


£ kc H : a: hre \K; A 2 ; H' 
fresh a fresh u 

D, =: a:\ rre \K[a/a], l:k ~ H' a 

E; T h^rut (Hx^h t; alt); k i; 0; iR;bf H Q 


D.8 Instantiation 

I lj^ st Instantiate so that a type’s first binder is more visible than v. 


fresh a v 2 < v\ 

^st «2[g/o] «2 H 

\^ st n^a: Re |/ci.K 2 a. re 2 ^ a:R e i«i,^ 

fresh a z/ 2 < Pi 

fj£. t /c 2 [a;/a] ip; k ' 2 H 

^ st II^aiReiKi. k 2 {a}, ?/;; k '. 2 H a:i rre |Ki,^ 


IInst Rel 


I Inst Irrel 


fresh t 

l^ st k 2 [l/c] ip; k ' 2 H Q 
fj^ st II| n f c\(p. K, t, ip; k 2 H t:(p, Q 


IlNST_CO 


V 1 < 1^2 


^ st «-w 0 ;«H 0 
“Less-visible-than“ relation 


IInst_Done 


- IVis Refl 

v < v 


U\ < U 2 U 2 < Ra 

Pi < vz 


Inf < Spec 


Spec < Req 


I Vis. 


IVis. 


IVis _ Trans 


InfSpec 


SpecReq 
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D.9 Subsumption 


l^-e « A;/c';t| Convert a kind into prenex form. 


v < Spec 

f^ re k 2 ^ A; /c 2 ; t 

f^ re k 2 5, A; /c 2 ; A(x: Re |n(5, A. /c 2 ), S. r (x dom(<5)) 


IPrenex_Invis 


^ re re 2 A; k' 2 \ t 

t 0 = A(a::ReinA, 8 . k 2 ), 8 . r (AA. x dom(A) dom(<5)) 
ipre n Req (5. K 2 A; n Req (5. K 2 \ Tq 


IPrenex_Vis 


---- IPrenex_NoPi 

K 0; hi] \x: Re \K. X 


Ki <* k 2 t H f]j “«i subsumes /c 2 .” (/c 2 is in prenex form) 


-w Ti H Qi « 2 [ri b/a] < /v 4 ^ r 2 H 0 2 

^ b Re |/C 3 ^ 2 ;£ 

To = Ax: R e|(na: R e|Ki.K 2 ),6:Rel«3.T2[^] (x(ti b)) 
n Req a:Rei/Ci. /c 2 <* n Req 6: R eiK 3 . re 4 t 0 H fii, ft' 2 


ISub_FunRel 


k 3 < -w Ti H Qi /c 2 [ti 6/a] < /c 4 r 2 H fi 2 

^ 6: Re |K3 f^ 2 ;£ 

T 0 = Ax: Re i(IIa:i rr eiKi. k 2 ), 6: Re i«3- t 2 [£] (x {n 6}) 
n Req «:i rre i^i- «2 <* n Req 6: Re |«; 3 . « 4 ^ t 0 H fix, ft' 2 


ISub_FunIrrelRel 


k 3 < -w ti H Qi /c 2 [ti b/a] < /c 4 t 2 H Q 2 

^2 ^ 6:i rre i«; 3 ^ 2 ;£ 

T 0 = Ax: Re i(na:i rr eiKi. /c 2 ), 6:i rre i«; 3 . t 2 [£] (x {n 6}) 

n Req a:i rre i«;i. k 2 <* n Req 6:| rre |/c 3 . /c 4 To H fii, fi 2 


ISub_FunIrrel 


fresh t 

Ti <* t 2 Ax: Re |Ti. (x > u) H jt:Ti ~ t 2 
/ci < /c 2 t H n I “/Ci subsumes /c 2 .” 


ISub_Unify 


^ re k 2 -w A^/c' 2 ;ti 

fer 

/c'l <* /c 2 -»t 2 HD 2 
Q 4 , 0 2 *—>• A £ 

«i < «2 Ax: Re iKi.Ti (AA. t 2 [£] (x^[f])) H 


ISub_DeepSkol 
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D.10 Generalization 

| fl 4 A O'; £ | Generalize Q over A. 


0 -A A 0;0 


IGen_Nil 


£o = ol dom(A) fl[£ 0 ] A 

a: p M A -w a : p V A, A'.k, fl'; £ 0 , £ 

£o = i 1 —^ dom(A) fi[e 0 ] A £ 

i : VA'.0,fi A -w t : V A, A'.0, £ 


IGen_TyVar 


IGen_CoVar 


D.ll Programs 


E; T l^jeci decl x : r := t Check a Haskell declaration. 


E; T l^| v fl -w A; © 

t' = AA. (t[0]) k' = n, nf A. [k[Q]) 

E; T f^ ec | x := t x : k' := r' 


IDecl_Synthesize 


E; r s (T H fli 

E; Rel(r) Rel(fii) ^ A i; 0! 

a' = II| n fAi. (<t[0i]) 

E; T t : a' r H 0 2 

E; r n 2 0; 0 2 

T> = r[0 2 ] _ 

E; r fr ed X :: s := t x : a' := t' 
E; T ^ rog prog r ; ; 9 | Check a Haskell program. 


IDecl_Check 


E; T ^ rog 0 


0 ; 0 


IProg_Nil 
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IProg_Decl 


E; T ^ ed decl x : k := t 
E; T, x: Re \K, c:x ~ r ^ rog prog P; 6 
E; T ^ rog decl; prog x:R e |R, c\x ~ r, P; ( t/x , (t)/c) o 0 
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Appendix E 

Proofs about the BAKE algorithm 


Throughout this appendix, I use a convention whereby in any case where the rule under 
consideration is printed, any metavariable names in the rule shadow any metavariable 
names in the lemma or theorem statement. 


E.l Type inference judgment properties 

Definition E.l (Judgments with unification variables). I write judgments with a new 
turnstile l=; these judgments are identical to the corresponding judgments written with 
a b except with the new rules as given in Appendix D. All lemmas proved over the old 
judgments hold over the new ones, noting that the new UVar rules are unaffected by 
context extension. 

Definition E.2 (Generalized judgments). I sometimes write E; ^ 1= J, where J 
stands for a judgment, one of the judgments headed by ^ 0 , fp rop , l^| t , ^ ec , ^ tx , or if. 
Similarly, I write J[6\ to denote substitution in the component parts of the judgment 

J. 

Lemma E.3 (Extension). 

1. J/SjThJ, then E; Thy. 

2. If E; T h J and J mentions no unification variables, then E; T b J. 

Proof. The difference between the b judgments and the b judgments is only the 
addition of new rules for new forms. No previously valid derivations are affected. 
Note that, although we can’t prove it now, the “mentions no unification variables” is 
redundant, as shown by Lemma E.ll, below. □ 


E.2 Properties adopted from Appendix C 

Remark. By the straightforward extension of the Rel(-) operation, all previous lemmas 
(Lemma C.3, Lemma C.4, Lemma C.5, Lemma C.6) dealing with contexts and relevance 
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remain true under the b judgments. 


Lemma E.4 (Type variable kinds [Lemma C.7]). (as stated previously, but with 
reference to b judgments) 

Proof. As before; the new forms do not pose any problems. □ 

Lemma E.5 (Unification type variable kinds). IfTi btx \l/ ok and a : p V A.k e \l/ 7 then 
there exists \k' such that \k' C Rel(\l/) and E; \k', Rel(A) by k : Type. Furthermore, the 
size of the derivation of E; tk', Rel(A) by k : Type is smaller than that of E btx ’k ok. 

Proof. Straightforward induction on E btx 'k ok. □ 

Lemma E.6 (Coercion variable kinds [Lemma C.8]). (as stated previously, but with 
reference to b judgments) 

Proof. As before; the new forms do not pose any problems. □ 

Lemma E.7 (Unification coercion variable kinds). If E btx T ok and t : V A.b e T, 
then there exists such that \k' C Rel(\l/) and E; tU, Rel(A) brop 4> ok. Furthermore, 
the size of the derivation of E; tl/', Rel(A) brop 0 ok is smaller than that of E btx ’k ok. 

Proof. Straightforward induction on E btx ’k ok. □ 

Lemma E.8 (Context regularity [Lemma C.9]). (as stated previously, but with refer¬ 
ence to b judgments) 

Proof. As before; the new forms do not pose any problems. □ 

Lemma E.9 (Weakening [Lemma C.10]). Assume E btx ’k 7 ok and C . If 
E;fNJ, then E; TNJ. 

Proof. As before; the new forms do not pose any problems. □ 

Lemma E.10 (Strengthening [Lemma C.ll]). (as stated previously, but with reference 
to b judgments) 

Proof. As before; the new forms do not pose any problems. □ 

Lemma E.ll (Scoping [Lemma C. 12]). (as stated previously, but with reference to b 
judgments) 

Proof. We must consider now Ty_UVar and Co_UVar. These cases are similar; 
let’s focus on Ty_UVar: 


CtlRelVA ,k£$ E btx 'k ok 

E; bee -0 : A 

E; T by : /c[V>/dom(A)] 


Ty_UVar 
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We see that a G {dom('h)}, and the induction hypothesis tells us that the scoping 
requirement holds for ip. Lemma E.5 tells us that E; W, Rel(A) ly y /c : Type for some 
\k' C Rel(\H). This derivation is smaller than the one ending in Ty_UVar, and so 
we can use the induction hypothesis to see that fv(/c) C ({dom(\H)} U (dom(A)}). 
The substitution in the conclusion removes all use of variables in dom(A), and so 
fv(/c) C {dom(\H)} as desired. □ 

Lemma E.12 (Determinacy [Lemma C.20]). (as stated previously, but with reference 
to N judgments) 

Proof. As before. □ 

Lemma E.13 (Type substitution [Lemma C.35]). IfE; if y a : k and E; \H, a: p K, \H'1= 
J, then E; T, \H'[cr/a] 1= J[a/a\. 

Proof. By induction on E; T, a: p K, W N J. We consider only the new cases. 

Case Ty UVar: 


o: Re |VA E^ tx ^ok 

E; ^ec ip '■ A 

E; T ^ : «#/dom(A)] 


Ty_UVar 


We must prove E ; \H, \H'[cr/ oj k y 07,^^ : K[ip/dom(A)][a/a]. (Recall that nor¬ 
mal substitutions 9 do not map unification variables.) We know a : Re | V A. k g 
T, a\ p K, \H', E ^ tx \H, a: p n, \H' ok and E; \H, a: p K, \H' ^ ec V’ : A. By the induction 
hypothesis, we can conclude E f? tx \H, \H'[cr/a] ok and E; \H'[<r/ a] o] : 

A[<j/a]. We now have two cases, depending on the location of a: 

Case a : R ei V A.k G T: In this case, Lemma E.ll tells us that A cannot mention 
a, and thus A[cr/a] = A. We can thus use «: Re |VA.K G \k to com¬ 
plete the premises for Ty_UVar, showing that E; T, T'[cr/ a] b y a J,[ a /a] '■ 
K[ip[a/a\/ dom(A)]. The kind can be rewritten as n ajd]\jp[(r/ a]/dom(A)|| 
as we know a ^ fv(/c). It can then further be rewritten to /c[V’/dom(A)][<j/o] 
as desired. 

Case a: Re |VA.K G 'll': It must be the case that a : Re i V (A[cr/a]).(/c[cr/a]) G 
\H'[cr/a]. Rule Ty_UVar then gives us S: \&, \&'[cr/a| ^ “V’Ka] : 
K,[a/a\[ip[cr/a]/dorr\(A)\ which can be (see above) rewritten as 
E; T, \H'[cr/a] tf y a^ CT / a ] : n[ip / dom(A)][cr / a\ as desired. 

Case Co_UVar: Similar to previous case. 


□ 

Lemma E.14 (Coercion substitution [Lemma C.36]). If E; 1 ^ 0 7 : cp and 
E; \H, c:cp , \P' 1= J, then E; T, ^'[ 7 /c] 1= ^[ 7 /c]. 
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Proof. Similar to previous proof. 


□ 


Lemma E.15 (Vector substitution [Lemma C.37]). J/E; 4/ ^ ec if : A and E; \L, A, 41' t= 
J, then E; V, #'[^/dom(A)] N J[f/ dom(A)]. 

Proof. As before, referring to Lemma E.13 and Lemma E.14. Note that this version is 
generalized to work over any judgment J while the previous proof lemma works only 
over by. This generalization poses no trouble. □ 


E.3 Regularity 

Lemma E.16 (Increasing relevance in vectors). If E; 4/ ^ ec fj : A, then E; Rel(T) ^ ec 
ff : Rel(A). 

Proof. Straightforward induction on the typing derivation, appealing to Lemma C.6. 

□ 

Lemma E.17 (Kind regularity [Lemma C.43]). J/E; 4/ if y t : k, then E; Rel(\U) tf y k : 
Type. 

Proof. By induction on the typing derivation. We consider only the new case: 

Case Ty UVar: 


cciRei VA.r e 4/ E ^ tx 4/ ok 
E; T l= ec ^ : A 

———- = - Ty UVar 

E;'!' ky % : «[^/dom(A)] 

We must prove E; Rel(\k) if y K^/dorr^A)] : Type. By Lemma E.8 and Lemma 
E.5, there exists 4/' such that 4/' C Rel(4i) and E; 4/', Rel(A) tf y k : Type. 
Lemma E.9 then gives us E; Rel(4>, A) h|, k : Type. Lemma E.16 tells us that 
E;Rel(4>) h^c V’ : Rel(A). We can thus use Lemma E.15 to get E; Rel(4>) tjy 
/c[ , 0/dom(A)] : Type as desired. 

□ 

Lemma E.18 (Proposition regularity [Lemma C.44]). If E; 4/ 7 : <f), then 

E; Rel(4>) N prop </> ok. 

Proof. The proof for the Co_UVar case is similar to the proof above for Ty_UVar. 
Other cases are as before. □ 
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E.4 Zonking 

Definition E.19 (Zonker). A zonker 0 is a substitution from unification variables a 
and i to types and coercions, respectively. Each mapping also includes a list of type 
and coercion variables under which it is quantified. 

0 ::= 0 | 0, \/z.r/a | 0, Vz. 7 /t 

Lemma E.20 (Zonker domains). If E;\l/ b © : O, then dom(0) = dom(O). 

Proof. By straightforward induction. □ 

Lemma E.21 (Zonking a relevant type variable). If a : Re i V A.k e ft, E; b © : O, 
no binding in O refers to a later one, and the range of 0 is disjoint from its domain, 
then there exists r such that Vdom(A). r/a e 0 and E; \l/, A[0] by r : «[©]. 

Proof. By induction on E; T 1= 0 : 0. 

Case Zonk_Nil: Impossible, as 0 is empty. 

Case Zonk_TyVarRel: We have two cases here: 

Case f l = a : Re i V A./c, ft': We see that 0 = Vdom(A). t/ck, 0', satisfying the 
first conclusion. The premise of Zonk_TyVarRel tells us E; T, A by 
r : k. By assumption, we know that A and k cannot refer to a nor any 
variables in O'. Thus A = A[0] and k = /c[0], and thus we can conclude 
E; A[0] ^ t : /c[0] as desired. 

Case O = a' : p V A'.k', O', with a^a': We see that 0 = Vdom(A'). t'/ck', ©'. 
Let 0 O = Vdom(A'). t'/ck'. We can further see that 

a: Re iV(A[0 o ]).(K[0o]) £ O'[© 0 ] and E; ^ 0' : O'[0 o ]. Because 
the range of 0 is disjoint from its domain and the fact that O is 
well-scoped, we know O'[0 o ] must be well-scoped. We can thus use 
the induction hypothesis to get r such that Vdom(A). r/a E 0' and 
E; \k, A[0 O ][0'] hfy r : /c[0 o ][0']. Because 0 is idempotent, we can rewrite 
this as E; \k, A[0] by r : k[Q] as desired. 

Case Zonk_TyVarIrrel: Like second half of previous case. 

Case Zonk_CoVar: Like previous case. 


□ 

Lemma E.22 (Zonking a coercion variable). If t : VA.0 e O, E; T b © : O, no 
binding in 0 refers to a later one, and the range of 0 is disjoint from its domain, then 
there exists 7 such that Vdom(A).7/t e 0 and E; A[0] bo 7 : 0[0]. 

Proof. Similar to previous proof. □ 


285 



Lemma E.23 (Zonking). //© is idempotent, E; T b © : Q and E; \l/, D, A 2 b J, then 

E;$,A 2 [e]NJ[e]. 

Proof. By induction on the derivation E; V, Q, A 2 b J. 


Case Ty Var: 


E btx T ok a: Re i«; £ r 
E; T hty a : k 


Ty_Var 


We know E btx \l/, Q, A 2 ok and a : Re \K e \l/, Q, A 2 . We must prove E; \l/, A 2 [@] by 
o[©] : k[G}. Zonking a non-unification variable (like a) has no effect, so we must 
prove E;\k,A 2 [©] by a : «;[©]. We will use Ty_Var, so we must prove the 
following: 


E btx tit, A 2 [0] ok: By the induction hypothesis. 

a: Re |/c[0] e \k,A 2 [©]: From a: Re |«; e \I/,f2, A 2 , we know that a must appear 
either in V or in A 2 . If a is in V, we are done, using Lemma E.ll to show 
that zonking k has no effect. If a is in A 2 , then a: Re i«[0] must be in A 2 [0], 
and so we are done with this case. 


Case Co_Var: Similar to previous case. 
Case Ty UVar: 


a : Re i VA.k G T E btx tit ok 

E; T bee ^ : A 

———-=- Ty UVar 

E;^ by : «[^/dom(A)] 

We know E; \l/, U, A 2 b y a^ : n[if/ dom(A)] and must prove E; T, A 2 [0] by a^[0] : 
/c[V’/dom(A)][©]. We further know that E; T, U, A 2 bee if : A By the induction 
hypothesis, E; T, A 2 [0] bee V’t©] : A[0] and E btx T, A 2 [0] ok. There are then 
several possibilities: 

Case a : Re i VA.r e tl/: By Lemma E.20, we know that dom(0) = dom(U). From 
E btx T, 0, A 2 ok and Lemma E.ll we know that nothing in T can mention 
any variable bound in O. We also know that a^[0] = and k[0] = k. 
The telescope A is mentioned in T and therefore is unaffected by the 
zonking substitution 0. We can thus conclude that a: Re |VA.K e V, A 2 [0] 
and E: T, A 2 [0] bee U[0] : A, We can thus use Ty_UVar to conclude 
E;\k,A 2 [0] by : «['0[0]/dom(A)]. We can rewrite this kind to be 

«J$/dom(A)][0] as desired because n[Q] = k. 

Case a : Re i VA.r e fh We then use Lemma E.21 to get E;\b,A[0] by r : 
k[Q] and Vdom(A). t/ol e 0. Thus (by Definition E.19) a^[0] = 

'^'[p(’0]/dom(A)]. Lemma E.9 gives us E; \b, A 2 [0], A[0] by W ■ «[©]• 
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The induction hypothesis tells us that E;\I/, A 2 [0] ^ e c 0[©] : A[0]. 
Now, we apply Lemma E.15 to get E;^/,A 2 [0] ky r[^[0]/dom(A)] : 
/c[0][V’[0]/dom(A)], which can easily be rewritten to E;\k,A 2 [0] Nf y 
r['0[©]/dom(A)] : /c[^/dom(A)][0] as desired. 

Case Co_UVar: Similar to previous case, but using Lemma E.22. 

Other cases: Similar to proof for Lemma C.35. 


□ 


E.5 Solver 

The solver (fi& v ) must have the following properties. 

Property E.24 (Solver is sound). //E i^ tx \H, Q ok and E; ^| v A; 0, then 0 
is idempotent, E l^ tx \I/, A ok, and E; 'll, A ^ 0 : fb 

E.6 Supporting functions 

Definition E.25 (make_exhaustive). Define make_exhaustive(a/t; k) as follows: 

make_exhaustive(a/t; fi) = alt ((_ —>■ t) e alt ) 

make_exhaustive(a/t; k) = alt] _ — >• errorn "failed match" (otherwise) 

E.7 Supporting lemmas 

Lemma E.26 (Vector extension). If E; A, \E f/ ^ ec 0 : A', then E;\1/,A, ^ ec 
dom(A),0 : A, A'. 

Proof. We know E l^ tx A, T' ok by Lemma E.8. Proceed by induction on the 
structure of A. 

Case A = 0: Trivial. 

Case A = a: p K, Ai: To use Vec_TyRel, we must show E; \l/, A, fl/' hj y a : k (which 
is by Ty_Var) and E; \l/, A, fi/ 7 ^ ec dom(Ai), if : (Ai, A ')[a/a\. The substitution 
clearly has no effect, so we are done by the induction hypothesis. 

Other cases: Similar. 


□ 

Lemma E.27 (Type variables instantiation). If E \^ tx a:\ rrei K ok, then E ly tx 
b\\ m \K[b/a] ok. 
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Proof. By induction on the length of k. 


Case k = 0 : Trivial. 

Case k — k',k 0 : Here, we know a = a', a 0 and b = b ,b 0 . Our assumption is that 
E btx a'veitd, a 0 : i rr ei K o ok. Inversion (of Ctx_TyVar) gives us E; by 

Kp : Type and E btx a , :\„ e \K? ok. The induction hypothesis tells us E btx 
b '.\„ e \K'[b /~a'] ok. We must show E; b : Re |/«'[& /a'] hty K. 0 [b /~a'\ : Type. Use Lemma 
C.10 (Weakening) to get E; b : Re |7c '[b /Ml, o': Re |/c / by k 0 : Type. Lemma C.39 
gives us E; b : Re | K'[b /a!] b ec b : ( b : Re |ic'[& /a']). We can thus use Lemma C.37 to 
get E; b : Re | K'[b/a'] hty K 0 [b /a'] : Type as desired. We then use Ctx_TyVar 
and we are done. 


□ 

Lemma E.28 (Decreasing relevance). //E btx ReI(H7) ok, then E btx ^ ok. 

Proof. Straightforward induction on E btx Rel(\P) ok. □ 

Lemma E.29 (Closing substitution substitution). 

1 . If E; T, a: Re i«;, U bubst 0 ■ A and E; T by a : k, then E; T, T'[<j/ a] hi ubst of a o 9 : 
A [a/a\. 

2. If E; T, a:| rre |K, D bubst 9 : A and E; Rel(T) by a : k, then S; T, T'fcr/a] bubst 
<7/a o 9 : A[cr/a]. 

3. If E; T, c:(j), T' bubst 9 : A and E;T bo 7 : (f, then E;T,T'[ 7 /c] bubst 7 /co# : 

A [ 7 /4 

Proof. By induction on the bubst derivation. We will consider the type substitution 
case; the others are similar. 

Case Subst_Nil: Trivial. 

Case Subst_TyRel: In this case, we know E;T, a\ p n, T' bubst 9 : 6: Re |K 0 , A and 
must show E;r,r'[cr/a] bubst a/ao9 : 6 : Re iACo[ cr / a ], A[cr/a]. Inverting gives us 
E; T, a: p K , V by b[9] : k 0 and E; T, a: p n , V bubst 0 ■ A[6>| 6 ]. To use Subst_TyRel, 
we must show E; T, T'[a / a] by b[aja o 9] : kq[g/ a] and E; T, Y'[a/ a] bubst cr/a o 9 : 
A[cr/a][(a/a o 9)\ b ]. The first of these is directly from the induction hypothesis. 
The induction hypothesis also gives us ,T'[cr / a] bubst <yjao9 : /S[9\ b ][a / a]. 

We are left only to show that A[9\b][cr/a] = A[cr/o][(cr/a o 0)| 6 ], On the right, 
we care only about #’s action on b, so we can rewrite to A[cr/a][a/a o (9 ]$).], 
which can then be rewritten to A[#b][cr/a] as desired. 

Case Subst_TyIrrel: Similar to previous case. 

Case Subst Co: Similar to previous case. 
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Lemma E.30 (Closing substitution). Assume E; T hi ubst 9 : A. Let 9' = #|dom(A)- 

1. If E; T, A, r by t : k, then E; I\ V'[9'] b y t[9'\ : k[9']. 

2. If E; r, A, r' h co 7 : 0, then E; T, T'[9'] b 0 7 [0'] : 

3. If E; T, A, T' h^ rop 0 ok, then E; T, T'[9'] h^ rop 0[0'] ok. 

4. If E; T, A, T'; a 0 alt : «, then E; T, T'[0']; a Q [ff] ^f ] alt[9'} : k[9']. 

5. If E; T, A, r bee 0 : A, then E; T, T’[9'] b ec -ifft] : A[0']. 
d. If E btx r, A, r ok, then E btx r, T'[0'] ok. 

7. If E; r, A, r b r — > r' ; then E; T, H[0'] b r[9'] —> t'[9']. 

Proof. By induction on E; T bubst 9 : A. By analogy with the E; t= J notation, I will 
use E; T b J to refer collectively to the judgments over which this lemma is defined. 

Case Subst_Nil: In this case, A = 0 and we are done by assumption. 

Case Subst TyRel: 


E; T by a[9] : k 
E; r bubst 9 : A[0| o ] 
S; r bubst 9 : a\R e \K, A 


Subst_TyRel 


We know E; T bubst 9 : a: Re \k,A and E; T, a: Re \ti, A, T' b J. We must prove 
s ; rbj[0| o,dom(A)]- We know E; V b y a[9\ : k and thus we can use Lemma C.35 
to get E; T, A[0| o ], T' [01 a ] b J[9\ a \. We then use the induction hypothesis to get 
S; r b J'[6 l | a ][0|dom(A)]- It remains only to show that 9\ a o 6>| d0 m(A) = 0| a ,dom(A)- 
This amounts to showing that dom(A) ff a[9] . We have this by Lemma C.12, 
and so we are done. 

Case Subst_TyIrrel: Similar to previous case. 

Case Subst_Co: Similar to previous case, referring to Lemma C.36. 


□ 


E.8 Generalization 

Definition E.31 (Generalizer). A generalizer £ is a mapping from unification variables 
to vectors: 

£ ::= 0 | £, a (->■ 0 | £, 1 1-4 0 




A generalizer can be applied postfix as a function. It operates only on occurrences of 
unification variables, acting homomorphically on all other forms: 


a HA 0! e £ => 

= 


otherwise 

«#] = 


i i —y 0 ! g £ =>• 

% 2 [^] = 


otherwise 

= 



Lemma E.32 (Generalization by type variable). If E; \l/, A, a : p V A'.k, \k' N J, then 
E;^,cr:pVA, A'.k;, A, ^'[cr ha dom(A)] 1= J[a ha dom(A)]. 

Proof. Let ( = dom(A). Proceed by induction on the typing derivation. The 
only interesting case is for unification variables: 

Case Ty_UVar: Here, we know E; T, A, a : p M A'.k, \k' t^ y j3^ : k 0 and must show 

E;$,a: p VA, A'.k, A,^/'[^] ^ /?^[£] '■ «o[£]- We have two cases: 

Case a — fi: In this case, we know p = Rel and k 0 = r[ 0/dom(A / )]. In order 
to use Ty_UVar, we must show E ^ \l/, cc :r 6 i V A, A'.k, A, \k'[£] ok (which 
we get from the induction hypothesis) and E; tk, a :R e i V A, A'.k, A, ^ ec 
dom(A), -0 : A, A'. We know E; \H, A, a : p V A'.k, \E f/ ^ ec : A'. The induc¬ 
tion hypothesis tells us that E; \I/, a : p V A, A'.k, A, \k'[£] ^ ec 0[£] : A'[£], 
However, we can see (Lemma E.ll) that A'[£] = A. Then, Lemma E.26 
tells us E; \b, a : P V A, A'.k, A, \k'[£] h^ ec dom(A),0[£] : A, A' as desired. 
Rule Ty_UVar gives us 

S;*,o:,VA, A'.k, A,#'[£] t% a dom(4) , w : K [dom(A),i/dom(A, A')]. 

Indeed we can rewrite the kind as re[/0/dom(A')] and we are done. 

Case a fi: As with other substitution properties, we must break into cases 
depending on where ft is, but all cases are straightforwardly shown by the 
induction hypothesis. 

Case Co_UVar: Similar to non-matching sub-case of previous case. 


Lemma E.33 (Generalization by coercion variable). //E;\I/, A, t : VA'.0, \k' N J, 
then E; \l/, i : V A, A'.fi, A, T'[i ha dom(A)] 1= J[l ha dom(A)]. 

Proof. Similar to previous proof. □ 

Lemma E.34 (Generalizer scope). If Q, ^A A Q';£, then dom(£) = dom(fl). 
Proof. Straightforward induction on Q <->■ A Q': 0 □ 
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Lemma E.35 (Generalization). If ft, ^ A and E;4/,A,n b J, then 

E;$,Q',AN J[£\. 

Proof. By induction on Q <—> A ft 1 ; (. 

Case IGen_Nil: By assumption. 

Case IGen TyVar: Here, we know = a : p V A'./c, fR and ft' = 

ck: p VA, A'.re, Let £ 0 = ol i-> dom(A). The first step is to show 

E;$,a:,,VA, A'.k,A,Q][^| 1= J[£o\. This is true by Lemma E.32. We 
know f2i[£ 0 ] ^ A O',; We then use the induction hypothesis to get 
E; \l/, a \ p V A, A'./c, fl[, A N c7[|o][£iJ- However, because the domains of £ 0 and £1 
are distinct (by the well-formedness of O), we can rewrite as E; T, O', A b 
as desired. 

Case IGen_CoVar: Similar to previous case, appealing to Lemma E.33. 


□ 


E.9 Soundness 

Lemma E.36 (Instantiation). J/E; \l/ by r : k and fb $t k ip;n! H 0, then E; \H, O by 
r v : k' and k' is not a U-type with a binder (with visibility v 2 ) such that v 2 < v. 

Proof. Let’s call the condition on the visibility of the binder (if any) of the result kind 
the visibility condition. Proceed by induction on the derivation of the fe st judgment. 

Case IInst Rel: 


fresh a 

f^ st K 2 [a/a ] 
fjf st %h: Re |/Cr. k 2 


V 2 < V\ 

w ip; k' 2 H O 
a, ip; n' 2 H aiReiKi, O 


IInst_Rel 


We must show that E; \P, a:: Re |/ti, 0 r a ip : k' 2 and that k 2 satisfies the visibility 
condition. We can assume that E; by t : n ;y2 a:R e |Ki. k 2 . By inversion by Ty_Pi, 
Lemma E.8, and Lemma E.4, we can see that E; Rel(\P) by K\ : Type. Thus 
E btx 4/, a: Re i/ci ok and Lemma E.9 gives us E; 4/, o: Re |/ci by t : U U2 a:R e \Hi. k 2 . 
Thus, Ty_AppRel gives us E; 4>, a: Re |/Ci by to; : n 2 [a/a\. The induction 
hypothesis then tells us that E; 4/, o: Re |/ci, by raip : k' 2 and gives us the 
visibility condition, as desired. 

Case IInst_Irrel: Like previous case. 

Case IInst_Co: Like previous cases, but appealing to Lemma E.6 instead of 
Lemma E.4. 
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Case IInst_Done: The typing rule is by assumption. The visibility condition is 
by the fact that no previous rule in the judgment applied. 


□ 


Lemma E.37 (Function position). If E; T hf y k : Type and ten Pi 
7 ; II; a; p 2 ; k 1 ; k 2 H t/ien E; \k, 7 : n ~ n Req a: P 2 Ki. /c 2 . 

Proof. By case analysis on the derivation of ten- 

Case IFun Id: 


ten n Req a: p /Ci. n 2 ; p 0 ^ (n Req a: p «i. n 2 ); II; a; p\ k x ;k 2 H 0 

Let k = II Req a\pK\. k 2 . We know E; T tf y n : Type and thus E; \k teo (k) : k ~ k 
as desired. 

Case IFun Cast: 


fresh t fresh /h, /9 2 

Q = ^UirreiType, ^ 2 :| rre ,Type, t:re 0 ~ n Req a: ff pi.^ 2 

- -—-——— ——- lr UN OAST 

>7un ^o; P *** v, 0; a; p; p\\p 2 H 

Let ^0 = ^^Uirrei Type, ^2:,^, Type and = $ 0 ,t:K 0 ~ n Req a: p/ di./ 3 2 . We 

hrst must show E btx tk' ok. We know E btx tk ok by Lemma E.8. Adding j3\ 
and (5 2 to \k maintains well-formedness; thus E btx v I / o ok. In order to add the 
binding for we must show that E; Rel(\ko) by ^0 : Type and E; Rel(\ko) by 
fJ R eq (i-pPi • /3' 2 : Type. The former is by assumption. The latter comes from 
E btx ^0 two uses of Ty_UVar, and a use of Ty_Pi. Thus E btx \I/ x ok 
and E; $1 t: k 0 ~ n Req a: p /?i ./? 2 as desired. 


□ 

Lemma E.38 (Scrutinee position). If E; \k by r : k and E; \k terut alt; k 
7 ; A; H'\t H Q, then E; \k, Q by r > 7 : IIA. H' r and E; Rel(\k, f T)^ H'r \ Type. 

Proof. By case analysis on the derivation for the terut judgment. 

Case IScrut Id: 


E; Rel(\k) b v Hr : Type 

-=-^--—- IScrut Id 

E; \k terut alt;TIA .Hr (’IIA. Hr); A; H\f H 0 

Let k = ’IIA. Hr. Working backwards from a use of Ty_Cast, we need to 
show that E; Rel(\k) bo (k) : k ~ re, and thus that E; Rel(\k) by k : Type. This 
comes directly from Lemma E.17. The second conclusion is assumed as a premise 
of ISCRUT_lD. 
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Case IScrut Cast: 


Eh tc H : ~a:\ rre \K', A 2 ; H' 
fresh a fresh t 

H = a:| rre |7cfa/al, l:k ~ H' a 

- - - IScrut Cast 

4/ l^ rut (H x —> t; alt); k t; 0 ; H aHfi 

Let 4 / 0 = ty,a:\ ne \K[a/a] and ’Ll = 4/ 0 ,t:K ~ H'a. We must first show 
that E htx v I / o ok. We know h^j g E ok (by Lemma E. 8 ). Lemma C.40 tells us 
E h^tx a:\ ne \K ok. Lemma E.27 and Lemma E.3 then tell us E l^ tx a:\ ne \K,\a/a] ok. 
We have E h| tx 4/ ok by Lemma E .8 and thus can use Lemma E.9 E b tx v I / o ok as 
desired. To show E l^ tx 4>i ok, we must now show that E; 4/ 0 n : Type and 
E; 'Lq fy H'a : Type. The former is by Lemma E.17 and Lemma E.9. For the 
latter: use Lemma C.41 and Lemma E.9 to see that E; 4/ 0 TTa:i rre iic, A 2 . H'a : 
Type. Repeated inversion on Ty_Pi tells us E; 4/ 0 , a:| rre |ic, A 2 hf y H' a : Type. 
Lemma E.10 gives us E; 4/ 0 , a: irrei K hf y H' a : Type. Lemma C.39 tells us that 
E; *0 h?ec « : («3rrei^[a/a])- We thus use Lemma E.15 to see that E; 4/ 0 hj? y H'a : 
Type as desired. We can thus conclude E ^ tx 'Ll ok by Ctx_UCoVar. We are 
done with the first conclusion by Ty_Cast and Co_Var. We get the second 
conclusion easily by noting that A = 0 and by Lemma E.17. 


□ 

Lemma E.39 (make_exhaustive). Assume that, Vi, E; 4/; T1A. H a Nf| t 

alti : k and alt = make_exhaustive(a/f; k). Furthermore, assume no 
pattern appears twice in alt. Then Vj, E; 4/; HA. H a fit altj : k and 
alt are exhaustive and distinct for H, (w.r.t. Ej. 

Proof. If there is a default pattern in alt, then make_exhaustive does nothing. In this 
case, the default pattern makes the alt exhaustive. We have already assumed they are 
unique. 

Otherwise, make_exhaustive adds a default. Assuming 
error:ReiII(a:i rr eiType), ( 6 : Re |String). a, we have Vj, E; 4/; T1A. H a tf| t altj : k, 
and indeed the alternatives are now exhaustive. □ 

Lemma E.40 (Prenex). T/E; Rel(\P) tf y k : Type and f^ re k A; k';t, then E; tit lf y 
r : Ila;:Rei(nA. n'). k. 

Proof. By induction on the f^ re judgment. 

Case IPrenex Invis: 


v < Spec 

Iple ^2 ' v '* A; k 2 ', t 

l^ re II „5. k 2 S, A; k' 2 ] A(x:ReiII(j, A. k 2 ), S. r (x dom(<j)) 


IPrenex_Invis 
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We know E; Rel(\I/) by n^. k 2 : Type. Inversion gives us E; Rel(\I/, 5) by 
k 2 : Type. The induction hypothesis thus tells us that E; T, S by t : 
0as:Rei(nA../4).« 2 . Let \F = \k, x: Re i(n5, A. k 2 ), 8. We need E btx h' ok, 
for which we need E; Rel(T) by 11(5, A. k' 2 : Type, which can be proved 
by inversions and Ty_Pi. We thus have E btx V L' ok. We now show that 
E;\F by r(xdom(<5)) : k 2 . First, we note that E; \F by xdom(5) : 1JA. k 2 by 
the appropriate application rule. (It depends on the relevance of 6.) There 
is no substitution in the kind, because we are applying to dom(<5). Thus 
E;\F by r(xdom((5)) : k 2 [x dom(<5)/a; 2 ] by Ty_AppRel. However, we know 
# ^2 by Lemma E.ll and so we are done by two uses of Ty_Lam. 

Case IPrenex Vis: 


ipre A; k' 2 ]T 

r 0 = A(x:ReiIIA, S. k 2 ), S. t (AA. x dom(A) dom(<5)) 
^re n Req (5. K 2 A; n Req (5. «' 2 ; To 


IPrenex_Vis 


We know E; Rel(\P) b y n Req (5. k 2 : Type. Inversion gives us E; Rel(T, 6) ^ k 2 : 
Type. The induction hypothesis then gives us E; \l/, 8 by t : n^iRe^nA. k' 2 ). k 2 . 
Let \F = H/, T: Re i(IlA, 8. k, 2 ), 8. We need E btx 'F ok, for which we need 
E; Rel(\l/) by IIA, 8. k' 2 : Type. This can be proved by inversions and Ty_Pi. We 
thus have E btx tl/' ok. We now show that E; \F by t (AA. x dom(A) dom(<5)) : k 2 . 
First, we show that E; \F, A by x dom(A) dom(<5) : k' 2 . Once we show that 
E btx T , \ ok (as can be shown by inversions, Lemma E.8, and Lemma 
E.9), then this comes directly from the type of x. Thus, we can conclude, 
by repeated use ofTY_LAM, that E; \F b y AA. x dom(A) dom(<5) : nA. k' 2 . Ac¬ 
cordingly, E;\F by t (AA. x dom(A) dom(<5)) : /c 2 [(AA. x dom(A) dom(<5))/x 2 ], 
but the substitution in the kind has no effect by Lemma E.ll. We thus have 
E; \F by t (AA. x dom(A) dom(<5)) : k 2 . We are done by several uses of Ty_Lam. 

Case IPrenex NoPi: 


:--- IPrenex NoPi 

K 0; K] \x: Re \K. X 

Assuming E; Rel(\P) b y k : Type, we must show E; T by Ax: Re |/Y x : LI:r: Re |K. k. 
This is true by straightforward application of typing rules. 


□ 

Lemma E.41 (Subsumption). Assume E; Rel(l/) by «i : Type and E; Rel(l/) by ft 2 : 
Type. If either 

1. K\<* k 2 ~* t H £1, OR 

2. < /{ 2 ^ T H fi 
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Then E; 'I', fl by r : IIa;: R ei/ci. k 2 . 

Proof. By mutual induction on the subsumption judgments. 


Case ISub_FunRel: 

K 3 < K\ Ti H fli K 2 [ti 6/a] < r 2 H 

fl 2 ^ 6 : R eiK 3 ^ 2 ; £ 

To = Aa:: Re |(na: Re |/ti. /c 2 ), fr: Re i^ 3 - t 2 [£] (x (n 6)) iSub FunRel 

ll-Req Ct-Rel^l- AC 2 ^ n Re q6. Re |/^3. K 4 To H Hi, H 2 

Our assumption says that E; Rel(\I/) by na: Re |fti. k 2 : Type and E; Rel(\I/) by 
]Ja: R eiF 3 - ^4 : Type. Inversion of Ty_Pi tells us the following: 

• E; Rel(^) by Ki : Type 

• E; Rel(d'), a: Re |/«i by k 2 : Type 

• E; Rel(d') by k 3 : Type 

• E; Rel(d'), 6: Re i«; 3 by «4 : Type 

The induction hypothesis then tells us E; dl, Oi by Ti : IIx'i: Re i/T 3 . K\. Lemma E.9 
gives us E; Rel(d>, Hi), 6 : Re |/c 3 , a: Re i«i by k 2 : Type. Rule Ty_AppRel tells us 
E; \R, Oi, 6 : Re i «: 3 hy T\ b : K\[b/x\, but Lemma E.ll tells us that the substitution in 
the kind has no effect. We can thus use Lemma E.13 to get E; Rel(\l/, Q1), 6 : Re i k 3 b y 
k 2 [ti b / a\ : Type. Now, we can use the induction hypothesis again to get 
E; T, Oi, 6 : Re |ft 3 , 0 2 by t 2 : na> 2 : Re |K 2 [ti b/a ]. /c 4 . Lemma E.35 tells us now that 
E; dt, fii, H 2 , 6 : Re i /«3 by t 2 [^] : (na^: Re i« 2 [ri bja] . K4)[fj 4 but Lemma E.34 tells us 
the [£] in the kind has no effect. Let 

fli, H 2 , x: Re i(IIa: R ei/ci. k 2 ), 6 : Re |K 3 . 

To show E btx d/' ok, we need only show that E; Rel(d/, Hi), fl 2 b y IIa: Re |/ci. k 2 : 
Type (noting that Lemma E.35 and Lemma E .8 imply E btx dM^.H^ ok), 
but this is true by Lemma E.9. We must now show E; d/' by t 2 [£] (x (ti b)) : k a . 
We’ve already ascertained that E; d r/ by Ti b : K\. We see that E; d ,/ by x (ti b) : 
%[ti b/a}. Thus E; dt' by t 2 [£] (x (ti b)) : k^x (ti 6 )/a^], but Lemma E.ll tells 
us that the substitution in the kind has no effect. We are thus done by two uses 
of Ty_Lam. 

Case ISub_FunIrrelRel: Similar to previous case. Note that b can be used 
irrelevantly even though it is bound relevantly. The opposite way would not 
work. 

Case ISub_FunIrrel: Similar to previous case. 
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Case ISub Unify: 


fresh t 

n <* T 2 AxiRelTi. (x > i) H f.Ti ~ T 2 


ISub_Unify 


We must show that E; \l/, l:t\ ~ t 2 by Ax:R e |Ti. (x > t) : IJxiReiTi. r 2 . Our last step 
will be Ty_Lam and thus we must show E; 4/, a:ti ~ t 2 , x:R e |7i 1%, x > t : t 2 , 
for which we only need show that E btx T, i\T\ ~ t 2 ok, for which we only need 
show that E; Rel(4>) ly y T\ ■ Type and E; Rel(4>) by r 2 '■ Type, which we know 
by assumption. We are done. 

Case ISub DeepSkol: 


fpte k 2 ^ n 

K\ lj}\ H Oj 

k \ <* k ' 2 ^ T2 H 0 2 
Oi, 0 2 1 —> A O'; £ 

«i < « 2 Ax: Re i/ci.Ti (AA. t 2 [£] (x^[£])) H 


ISub_DeepSkol 


We must show E; 4/, O' by Ax: Re |/Ci. Ti (AA. t 2 [£] (x V>[£])) : nx: Re i«;i. k 2 . The last 
step will be Ty_Lam, so we must show E; 4/, O', x: Re |/Ci by A (AA. t 2 [£] (xt/>[£])) : 
k 2 . From E; Rel(4i) by K i : Type, we can use Ctx_TyVar to see E btx 
4/,x:R e |Ku ok. Thus E; 4/, x:R e i«;i by x : K\. Lemma E.36 then tells us 
that E; \1/, xiRei^i, Oi by x-0 : k[. We then know (by Lemma E.17) that 
E; Rel(\l/, xiRei^i, Oi) by «[ '■ Type. Lemma E.40 tells us that E; 4/ b y n : 
nxi: Re i(riA. k' 2 ). k 2 . Lemma E.17 and inversion gives E; Rel(4>, A) b y k 2 : Type. 
We can then use the induction hypothesis with context 4/, x: Re \K U A, Q 1 (known 
well-formed by Lemma E.9) to get E; 4/, x:R e |Ki, A, Oi, 0 2 by t 2 : Llx 2 :Rei«;' 1 . k' 2 . 
Lemma E.35 shows that E; 4/, x:R e |/ci, O', A by t 2 [£] : (nx 2 :R e |K / 1 . /c' 2 )[£]. The 
kind can be rewritten to 11x2 :R e i («b [£]) • k 2 [£j but Lemma E.34 tells us that 
= « 2 . AVe established earlier that E; 4i, x: Re |/Ci, O x by xif) : k\. We can 
weaken this to E; 4i, x:R e |fti, A, 0 1; 0 2 by xifr : and then use Lemma E.35 

to get E; T, xiRei^i, O', A by (x.^OM : k\ [£. We know that x[£] = x be¬ 
cause x is just a non-unification variable. Rule Ty_AppRel thus gives us 
E; T, xiRei^i, O', A by t 2 [£] (x-0[£]) : K z[ x 4 ’[£.]/ x 2] but Lemma E.ll tells us that 
the substitution in the kind has no effect. We now use Ty_Lam (repeatedly) 
to see E; 4/, x: Re |/Ci, O' b y AA. t 2 [£] (x -0[£]) : IJA. k' 2 . Thus Ty_AppRel tells us 
E; 4/, xiReiKi, O' by n (AA. t 2 [£] (x^>[£])) : k 2 [~(AA. t 2 [£] (x-0[C]))/a], but Lemma 
E.ll tells us that the substitution in the kind has no effect. We only need to 
reshuffle the context; in other words, we must now show E btx 4i, O', x:R e |Ki ok 
to be done. For this to hold, we need to know that none of O' depend on x. First, 
note that x is local to rule ISub_DeepSkol. We see that A is produced by f^ re 
with no mention of x, Ox is produced by fe st with no mention of x, and 0 2 is 
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produced by <* with no mention of x. Therefore, x is not mentioned in any of 
these, and we are done. 


□ 

Lemma E.42 (Type elaboration is sound). 

1. If any of the following: 

(a) E btx \l/ ok and E;f ^t^r:«:HO, OR 

(b) E btx * ok and E; $ t ^ r : k H fi, OR 

(c) E; Rel(\I/) by k : Type and E;f ^ti/t^rHO, OR 

(d) E; Rel(^) by k : Type and E;$^t:K^rHO 

Then E; 'll, 1%, r : k. 

2. If E btx ok and E; T b| s a H Q, then E; Rel(\l/, Q) b y a : Type. 

3. If E; T by ri : U„a: p Ki. k 2 and E; T; p t 2 : n\ V> 2 ; t 2 H fi, then E; T, Q, b y 

Ti^2 : K 2 [r 2 /a]. 

4. If E; Rel(\I/) by k : Type, E; ^ by r 0 : UA.Hr, E; Rel(T) by Hr : Type, and 
E; \l/; HA. Hr ;To bit alt : k alt H Q, then E; 'll, 0; HA. Hr if° t alt : k. 

5. If E; Rel(tf) by k : Type, E; T by t 0 : TlA.Hr, E; Rel(T) by H¥ : Type, and 
E; \l/; k 0 ; r 0 bite alt : k alt H fl, then E; \l/, 0; k 0 if° t alt : k. 

6. If E btx ok and E; T l^qvar a : k\ v H Q, then E; Rel(T, fl) by k ■ Type. 

7. If E fax 'L ok and E; T bi| aqvar a : k H £1, then E; Rel(\l/, Q) by k : Type. 

8. //E; T ^ t 0 : k and E; T b^ aqvar : k -w a : x.t H f/ten E; T, fl by t[t 0 /x] : 

k' . 

Proof. Proceed by induction on the structure of the type inference derivation. 


Case ITy Inst: 


E;4 f (^t~^T:«;Hfli 

lg c k -w k' h n 2 

E;$bt-^Ti):fvH fli, fl 2 


ITy_Inst 


The induction hypothesis gives us E; \l/, fi x by t : k. Lemma E.36 then gives us 
E; \l/, fli, fl 2 by t4> : k' as desired. 

Case ITy_Var: By Ty_Var and Lemma E.36. 
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Case ITy App: 


E; \l/ ti Ti : k 0 H Qi 
fen k 0 ; Rel 7; II; a; p; Kq; k 2 H fl 2 
E; Hi, ^ 2 ; P ^ rg t 2 : /ci - 0 2 ; t 2 H 0 3 App 

E; \l> ti t 2 -w (n > 7) -02 : «2[T 2 /a] H fR, fl 2 , fl 3 _ 

The induction hypothesis tells us that E; T, Qi by 77 : kq. Thus E; Rel(\l/, Hi) by 
k 0 : Type by Lemma E. 17 . Lemma E .37 tells us that E; Rel(\I/, fid, fl 2 ) bo 7 : 
n 0 ~ n Req a: p K7. n 2 . Rule Ty_Cast gives us E; T, 0 l5 fl 2 by A>7 : n Req a: p Kq. k 2 . 
Another use of the induction hypothesis (for the |A g premise) gives us our desired 
outcome. 

Case ITy_AppSpec: By induction. 

Case ITy_Annot: By induction. 

Case ITy Case: 

E; ^ t 0 7o_: k 0 H flo 

E; fl 0 l^ rut alt; k 0 7; A; H'\ r H fl' 0 

fresher fl' = fl 0 , fl' 0 , a:i rre |Type 

Vi, E; \H, fl'; ’IIA. H' r; To > 7 life alt* : o; alti H fl, 

alt = make exhaustive( alt: k) 

- -^—VA-—-- ITy_Case 

E; 1 ^ case to of alt case a (to > 7) of alt : a H f V, ft 

The induction hypothesis tells us that E; T, O 0 by t 0 : «o- Lemma E .38 tells 
us that E; \l>, fl 0 , fl(j by To > 7 : ’IIA. H't and E; Rel(\R, fl 0 , Q' 0 ) by H't : Type. 
Rule Ctx_UTyYar gives us E btx O' ok. The induction hypothesis (for life) 
tells us that, Vi, E; \l>, IT, Qf, ’IIA. H't If^ 7 alti '■ «• Lemma E .39 then tells us 
that alt are well-formed and exhaustive. Lemma E .9 (and Lemma E.8 on the bit 
judgments) allows us to combine all the f into ft. We are done by Ty_Case. 
Case ITy Lam: 

E; \I/ l^qvar a : «q; v H fli 
E; \I/, fti, a: Re |Ki 1 ^ t r : n 2 H fl 2 
ft 2 a: Re |Ki fl 2 ;£ 


E; T l| Aqvar. t Aa: Re |Ki. (r[£]) : rRa: Re |Kq. (/c 2 [f]) H Qi, fl 2 


ITy Lam 


The induction hypothesis (on 1^) tells us that E; Rel(Y, Qi) by «i : Type. 
Thus E btx V R Oi, a: Re |«i ok and we can use the induction hypothesis to get 
E; T, fti, o: Re |/ci, ft 2 by t : k 2 . By Lemma E.35, we get E; \k, fti, fl' 2 , a: Re i«i by 
t[£] : ^ 2^] and thus E; vR Q, J1' 2 fry Aa: Re |fti. (t[£]) : n„a: Re |Kq. (k 2 [£]) as desired. 
Case ITy_LamIrrel: Like previous case. 




Case ITy_Arrow: By induction and Lemma E.9 
Case ITy_MArrow: By induction and Lemma E.9 
Case ITy Fix: 


S; f 1^ t ^ t : /« H fii 

ifg n k: Rel 7 ; II; a; Rel; K\: k 2 H H 2 

E; Rel(\l/, f^, fi 2 ) b y k 2 : Type 

fresh l H = Qi,Q 2 , l:k 2 ~ K\ 

- ITy Fix 

E; 1/ fixt ^ fix (t > (7 9 Ua: Re \(Ki). l)) : Ki H H 

The induction hypothesis gives us E; I/, by r : k and thus E; Rel(\I/, 0 1 ) by 
k : Type by Lemma E.17. Lemma E.37 gives us E; Rel(\I/, O l5 0 2 ) bo 7 : k ~ 
nReqfl-Rei^i- ^2 and then Ty_Cast tells us E; H, Qi, tt 2 b y r >7 : nR eq fl: Re |Ki. k 2 . 
Thus, Lemma E .8 tells us £ fex T, f2i, fl 2 ok. In order to prove £ fex H ok, we 
must show E; Rel(\H, Hi, fl 2 ) by k 2 : Type and E; Rel(\I/, fix, fi 2 ) by K\ : Type. 
The first of these is a premise to ITy_Fix. To get the second, we use Lemma 
E.17 to get E; Rel(\I/, fb, fi 2 ) by IjReqaiRei/C!, k 2 : Type and then invert. We can 
conclude E btx H ok by Ctx_UCoVar. 

Inversion on E; H/, Hi, H 2 by r > 7 : nR eq a:R e |fti. k 2 tells us that E; Rel(\I/, O) bo 
7 : k ~ IlR eq a:ReiKi. k 2 . We can further see (by Co_PiTy) that E; Rel(\l/, fi) bo 
Ua:R e \(ni) . t : (IlaiReiKi. k 2 ) ~ (na:R e i«7. (fti[a>sym («;i)/a])) However, because 
a # Ki (by Lemma E.ll), that last substitution has no effect, and so we 
conclude E; Rel(\H, H) bo no: Re i(/Ci). 1 : {t£-a: Re \Ki. k 2 ) ~ (Ila: Re \Ki. Ki) and thus 
E; \H, H by r>( 79 lJa:Rei(/ci). t) : IlaiReiKi. K\. Finally, Ty_Fix gives us E; \H, H by 
fix (r > (7 9 na: Re |(/ci). t)) : K\ as desired. 

Case ITy Let: 


E; T ti Ti : K\ H H 

E; T, H, a;:Rei«;i |t 2 ^T 2 :K 2 Hl] 2 

H 2 x:Rei«;i 

Ej'L lets := tiint 2 -w (\x: Rei Ki. (t 2 [£]))ti : k, 2 [£][ti/x] H fi, fi ' 2 


ITy _ Let 


The induction hypothesis gives us E; \F, O b y n : k \. Lemma E.17 tells us 
E;Rel(\I/,H) by K\ : Type and thus that £ btx H/, H, £: Re |Ki ok. Another use 
of the induction hypothesis gives us £; ^/, H, xiRei^i, H 2 by t 2 : k 2 . Lemma 
E.35 then gives us E; \H, H, fl 2 , x: Re |Ki by t 2 [£] • k 2 [£\ and thus E;^,H,H 2 by 
AxiRei^i. (t 2 [^]) : Ux: Re \Ki. (/c 2 [£]) Rule Ty_AppRel gives us E;^/,H, fl 2 by 
(Ax: Re |/ci. (t 2 [C]))ti : Kulgllnjx] as desired. 

Case ITyC_Case: Similar to the case for ITy_Case. The only differences are 
the definition of O' (which is simpler in this case) and the use of bite in place of 
lilt- Both bit and bite are proven sound via the induction hypothesis. 













Case ITyC LamDep: 


fen re; Rel 7 ; II; a; Rel; «i; re 2 H Ho 

~'( a 4j ^ 2 ) 

E; Rel(tf) 

fi = fi 0 , Hi, l:ki ~ re'i 

E; 4/,H, b:R e \K,[ 1^ t : re 2 [& > symt/a] ^rHH 2 
H 2 b ;Rei ac 1 H 2 ;£ 

77 = re 2 [(a > t) > symt/a] ~(Ty P e) « 2 
T 0 = (AaiRei/Cj. (T[^][a > t/b\ > 77 )) > sym7 

E; te -M a :: s )-1 : k t 0 H H, fi' 2 


ITyC_ LamDep 


We have assumed E; Rel(4/) re : Type and thus can use Lemma E.37 to get 
E; Rel(4t, fi 0 ) 7 : re ~ n Req a: Re |rei. re 2 . (The -i(a # re 2 ) premise is not used in 
this rule; it is used to filter out which cases are handled in the next one.) By 
Lemma E.8, we have E ^ tx Rel (W) ok and thus can use the induction hypothesis to 
get E; Rel(4>, Hi) hf y k[ : Type. We must now prove that E; Rel(4>, H), &: Re \k[ 1%, 
k 2 [b > symt/a] : Type. First, we prove that E l^ tx Rel(4/,fi), &: Re ire'i ok. For 
this, it is left to prove only that E; Rel(\I/, fi 0 , Hi) l^y rei : Type. This we can 
get from Lemma E.18, inversion of Ty_Pi, and Lemma E.4. The inversion 
of Ty_Pi also tells us that E; Rel(4>, fi 0 ), a: Re |/ci k y k 2 : Type. Lemma E.9 
allows us to weaken this to E; Rel(4/,H), 6 : Re i/^i, a: Re irei Ify ^2 : Type. We can 
see that E; Rel(4/,fi), 6 : Re itti ky b > symt : rei. We thus use Lemma E.13 to 
get E; Rel(\P,H), b: Re \ k[ lf y K 2 [b > symt/a] : Type as desired. We then use the 
induction hypothesis to get E; 41, H, b: Re \K[, fi 2 l^ y r : K 2 [b > sym t/a]. Lemma 
E.35 allows us to rewrite this to E; 4/, H, fi 2 , &: Re ire'i try t[£] : n 2 [b > symt/a][£], 
but Lemma E.34 tells us the [£] in the kind has no effect. Lemma E.9 allows 
us to weaken this to E;4/,fi,fi 2 , a: Re |tci, b: Re ire'i 1%, t[£] : K 2 [b > symt/a]. We 
can see that E; 4/, H, H 2 , a: Re |tti 1^, a > t : k[ and thus we can use Lemma E.13 
to get E; 4>, H, H 2 , a: Re |tti ff y "T"[^] [« > t /b\ : K 2 [b > sym t/a] [a > i/b\. Inlining 
substitutions, we can rewrite the kind to re 2 [(a > t) > symt/a]. We can then 
see that E; 4/, H, fi 2 , a: Re itci by ^f§jjtt > i/b\ > 77 : re 2 and by Ty_Lam that 
E;4/,H,H 2 by Aa: Re irei. (t[£][o > t/ 6 ] >77) : na: Re |Ki. k 2 . A use of Ty_Cast 
gives us E; 4/,H,H 2 b y (Aa: Re |/Ci- (r[£][a > t/b\ > 77)) > sym 7 : re as desired. 

Case ITyC Lam: 


ten k; Rel 7 ; II; a; Rel; rei; re 2 H H 0 
E; 4/ te, aqvar : rei 6 : re' : ; x.Ti H Hi 
E; 4>, H 0 , Hi, b: Re \K[ |t:K 2 ^rHH 2 
H 2 b: Rei/c'i H 2 ; £ 
fi / = fi 0 , Hi, H 2 

E; 4/ te Aaqvar. t : re (Aa: Re |t«i. ^[6]bi[a/|Sl/&]) > sym 7 H fi' 


ITyC_ Lam 
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Lemma E.37 tells us E; Rel(\k, fl 0 ) h=o 7 : K ~ nR eq o:R e |/ci. k 2 . Lemma E.18 and 
inversions tell us E; Rel(\k, fio) hiy ft 1 : Type and E; Rel(\I/, f2o)> « ; Reifti hy ft 2 • 
Type. We can conclude E ^ tx Rel(\k, fio)> « : Rei^i ok and thus (using Lemma 
E.28) S; \I>, O 0 , a: R ei/«i by a : Kq. The induction hypothesis on then tells us 
E; \17, Q 0 , aiRei^i, fii by Ti [a/x] : k' v We can see by the construction of Qi and k[ 
that a # Oi and a -ft- ft'i- Because we are in rule ITyC_Lam, it means that 
ITyC_LamDep does not apply. This can be for one of two reasons, and thus 
we now have two cases: 

Case aqvar = a (unannotated binder): In this case, we see (by IAQ- 
VarC_Var) that k\ = K\. We can choose a = b by the ct-renaming. 
Thus, E; Rel(^,fl 0 ), b: Re \K,[ b y k 2 : Type. 

Case a # k 2 : We now use Lemma E.10 to get E; Rel(\I/, fl 0 ) by ft 2 : Type. 

Regardless of which case above we are in, we now must prove E btx 
\I/, Oo, Oi, b :R e iok. To do this, we must show only that E; Rel(\I/, £2i) by 
k\ : Type, which comes from Lemma E.17 and Lemma E.10. We can then use 
Lemma E.9 to get E; Rel(\l/, Oq, fb), fftReifti by K 2 ’■ Type. The induction hypoth¬ 
esis now applies to get E; 4/, r2 0 , Hi, b: Re \K,[, il 2 b y r : k 2 . Lemma E.35 tells us 
E; T, O 0 , , Q' 2 , 6:R e i k\ by t[£] : /v 2 [<C], but Lemma E.34 tells us the [£] in the kind 

has no effect. Lemma E.9 gives us E; \R, O 0 , a:R e |fti, fR, fi 2 , b: R e |fti by t[£] : k 2 . 
We can thus use Lemma E.13 to get E; T,fl 0 , a:R e iftl, tli, ^2 by t[£][ti[o/®]/&] : 
K 2 [Ti[a/x]/b\, but Lemma E.ll tells us the substitution in the kind has no effect. 
Noting that, by analysis stemming from our two cases previously, a # Q 2 , 
we can reshuffle the context to be \k, fi 0 , fh, fi 2 , a : Re \Ki and thus conclude 
E; M/, Q 0 , ^ 1 , ^2 by Aa:Rei/ci.r[^][Ti[a/x]/6] : Ua:R e \Ki. k 2 . Thus Ty_Cast gives 
us E; 4/, Q 0 , ^2 by (Aa:R e ifti. T[£][Ti[a/x]/b]) >sym 7 : k as desired. 

Case ITyC_LamIrrelDep: Like case for ITyC_LamDep. 

Case ITyC_LamIrrel: Like case for ITyC_Lam. 

Case ITyC Fix: 


E;^^t:nRe q a: R ei^/t^THn ITyC p 

E; T ^ fixt : n -w fixr H ~ 

We know E; Rel(\k) by k : Type. We can thus conclude by Ty_Pi that 
S; Rel(\I7) by IlaiReiK. k : Type. We thus use the induction hypothesis to get 
E; 4>, by t : na: Re |K. k. Thus we are done by Ty_Fix. 
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Case ITyC Infer: 


^ re k 2 A; k' 2 ; t 2 
O ^ AO'; & 

«i[ 6 ] <* k 2 r 2 h o 2 
o 2 a o 2 ; £2 

E; T ^ t : k 2 — r 2 (AA. t'[<£ 2 ] t[&]) H O', 0' 2 


ITyC_Infer 


The induction hypothesis tells us that E; 41, O by t : K\. We have assumed 
E;Rel(4>) by k 2 : Type. We can thus use Lemma E.40 to get E; 4/ by r 2 : 
ILr:Rei(nA. d 2 ). n 2 . Lemma E.17 and inversion gives us E; Rel(4/, A) by « 2 : Type 
and thus Lemma E .8 and Lemma E.28 give us E btx 41, A ok. We can thus 
use Lemma E.9 to get E; 4/, A, 0 by r : Ki and then Lemma E.35 to get 
E;4/,0',A by t[£i] : ki[£i]. Lemma E.17 tells us E; Rel(4>, O', A) by ki[£i] : 
Type and Lemma E.9 tells us E; Rel(4/, O', A) by d 2 : Type. We can thus use 
Lemma E.41 to get E; 4/, O', A, 0 2 by t 2 : nx:R e i(/ci[^i]). d 2 . Lemma E.35 then 
tells us E; 4>, O', 0' 2 , A by t 2 [£ 2 ] : (lLr: Re i(Ki [£ 1 ]). d 2 )[£ 2 ], but Lemma E.34 tells 
us that the [£ 2 ] in the kind has no effect (because neither d 2 nor K\ nor 
can mention anything bound in 0 2 ). We thus have E; 4/, O', 0' 2 , A by T 2 [£ 2 ] : 
IIa::Rei(/ci[^i]). d 2 . Ty_AppRel (with Lemma E.9) tells us E; 4>, O', 0' 2 , A by 
t 2 [£ 2 ] t[^i] : k' 2 [t[^i]/x] but Lemma E.ll tells us that the substitution in the kind 
has no effect. Multiple uses of Ty_Lam gives us E; 4/, O', 0 ' 2 by AA. t 2 [£ 2 ] t[£i] : 
1IA. d 2 . Yet another use of Lemma E.9 and Ty_ AppRel gives us E; 4/, O', 0 ' 2 by 
t 2 (AA. t 2 [£ 2 ] t[£i]) : k 2 [AA. t 2 [£ 2 ] t[£i]/|§| where Lemma E.ll tells us that the 
substitution in the kind has no effect. We are thus done. 

Invisible A/A cases: Like corresponding visible A/A cases. Note that the difference 
between the and checking judgments is relevant for user-facing issues of 
type inference (e.g., principal types), not the soundness we are proving here. 

Case ITyC_Let: Similar to case for ITy_Let. The only difference is that the 
expected type is propagated down. 

Case ITyC Skol: 


v < Spec 

E; 4>, $a: p Ki 11 : /c 2 ^ r H O 
O c —>• Saip^i O'; £ 

E; 4/ t : n^Sayci. k 2 \%a: p K\. t[£] H O' 


ITyC Skol 


We have assumed E; Rel(4>) by n„$a: p /ci. k 2 : Type. Inversion gives us 
E; Rel(4/), $a: Re |/v. 1 by k 2 : Type, and we can thus use the induction hypothesis to 
get E; 4>, %a: p K 1 , O b y r : k 2 . Lemma E.35 tells us E; 4>, O', $a: p Ki by r[£] : k 2 [£], 
but Lemma E.34 tells us that the [£] in the kind has no effect. We can thus 
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conclude E; 'll, Q' A$a: p Kq. (t[£]) : Y\. u %a\ p K\. k 2 as desired. 
Case ITyC_ Otherwise: By induction. 

Case IPtC Pi: 


fpf quant II; p 
E; \l/ l^qvar a : n; v H fl 

E; \l/, f1, a: p K s ^ c H 0 2 

fl 2 ^ ci-pK ^ 2 ; £ 

E; ^ f^ t Vqvar. s n^a: p K. (cr[£]) H Q, Q! 2 


IPtC_Pi 


The induction hypothesis (on 1^) tells us E; Rel(\P, O) ly y k : Type. Thus E l^ tx 
Rel(\P, n, cl: p k) ok and we can use the induction hypothesis (on f^) to get 
E; Rel(\l/, Q, a: p K, fi 2 ) Ny cr : Type. Lemma E.35 gives us E; Rel(\P, Q, Q 2 , a: p K ) tjy 
cr[£] : Type and thus E; Rel(\l/, O, Q 2 ) II a\ p n. (cr[£]) : Type as desired. 

Case IPtC Constrained: 


E; \P 1^ t : Type 

E; \l/, 61 , $a: Re |T ^ s a H fl 2 

fl 2 SaiRelT f2' 2 ;£ 

E; ^ t =*> s IJinfSaiReiT. (cr[£]) H Q! 2 


IPtC _ Constrained 


Lemma C.38, Lemma E.9 and Lemma E.3 tell us E; Rel(\I/) f^y Type : Type 
and thus we can use the induction hypothesis on to get E; \P, Qi ly y t : Type. 
We thus have E H=tx T, Q], $a: Re |T ok and can use the induction hypothe¬ 
sis on ^ to get E; Rel(\I/, fl 4 , $a: Re |T, fl 2 ) hf y cr : Type. Lemma E.35 gives 
us E; Rel(\P, 0 4 , fl 2 , $a:R e |T) hf y cr[£] : Type and thus E; Rel(T, 0 4 , fl 2 ) h|, 
II| n f$a:ReiT. (cr[£]) : Type as desired. 

Case IPtC_Mono: By induction. 

Case IArg_Rel: By induction and straightforward use of typing rules. 

Case IArg_Irrel: By induction and straightforward use of typing rules. 

Case IAlt Con: 


E ly c H : Ai; A 2 ; H' A 3 , A 4 = A 2 [r/dom(A 1 )] 
dom(A 3 ) = x dom(A 4 ) = dom(A / ) 
match{ dom (A 3 )} (types( A 4 ); types( A')) = Just# 
E;^A 3 ^t:K^rH9 
II ^A A 3 IT; £ 

A 3 = A 3 , c:t 0 ~ H {T } x 

E;T; ’Ll A'. H’T-,T 0 \&Hx^t:K~*H^ AA' 3 . (r[£]) H ft' 


IAlt_Con 


We wish to prove E; T, O'; ’Ll A'. H'f tf^ H -A AA 3 , (c:t 0 ~ % } x). (t[£]) : k, 
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given the premises above along with 

• E; Rel(tf) by k : Type 

• E;^ by t 0 : 'I I A'. H'r 

• E;Rel(tf) by H'r : Type 

We will use Alt_Match. This requires the following: 

E be H : Ai; A 2 ; H': This is a premise above. 

A 3 ,A 4 = A 2 [T/dom(Ai)]: This is a premise above. 
dom(A 4 ) = dom(A / ): This is a premise above. 

match{ dom (A 3 )}(types(A 4 );types(A / )) = Just#: This is a premise above. 

E; \&, Q! by AA 3 , (c:t 0 ~ H^} x). (t[£]) : HA 3 , c:t 0 ~ H dom(A 3 ). k: Let vp' = 
4>, fT, A 3 , c:t 0 ~ H[ T } x. We must show only that E; 4/' by t[£] : k. (Note 
that dom(A 3 ) = x, which is the one discrepancy between the quantified 
contexts above.) To use the induction hypothesis on 1^, we must show 
E; Rel(4>, A 3 ) by « : Type, which means we must show only that E btx 
\H, A 3 ok and then use Lemma E.9. Lemma C.40 gives us E btx A 4 , A 2 ok 
and by Lemma E.3, E btx Ai,A 2 ok. Lemma C.77 gives us E be H' : 
0; Rel(Ai); Type. We know E;Rel(4/) by H'r : Type. By Lemma C.42 
(easily updated to use b judgments), we can see that E; RelfT) bee T : 
Rel(A 4 ) and thus Lemma E.15 tells us E btx A 2 [r/dom(A 1 )] ok and by 
Lemma E .8 and Lemma E.9, E btx 4/, A 3 ok as desired. We have concluded 
that E; Rel(4>, A 3 ) by « : Type and so can use the induction hypothesis 
to get E; 4>, A 3 , by r : k. Lemma E.35 tells us E; 4>, Q', A 3 by t[£] : «[£], 
but Lemma E.34 tells us that the [£] in the conclusion has no effect. The 
last step here is to use weakening to add the binding for c to the context. 
This requires proving only that E; Rel(\1>, Q', A 3 ) b y H{t} x : ’IIA 4 . H'r. We 
can see that E; Rel(4/, Q', A 3 ) by 77{r} : TIA 3 , A 4 . H'r by Ty_Con. We are 
thus done by Lemma C.31 (easily updated for b judgments). 

Case IAlt_Default: By induction and Alt_Default. 

Case IAltC_Con: This case is identical to that for IAlt_Con. The difference is 
the assumptions that can be made when solving for the unification variables in 
fl, which does not affect the course of this proof. 

Case IAltC_Default: Similar to the case for IAlt_Default. 

Case IQVar_Req: By induction. 

Case IQVar_Spec: By induction. 

Case IAQVar Var: 


fresh j3 

E; b> q a a : /3 H /h| rre ,Type 


IAQVar_Var 
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We must show only that E; Rel(\&),/3:R e |Type by /3 : Type. This is true by 
Ty_UVar. 

Case IAQVar_Annot: By induction. 

Case IAQVarC Var: 


——-— IAQVarC Var 

E; 4/ a : k a : k ; x.x H 0 — 

Given E; 4/ by t 0 : /c, we must show E; 4/ by x[t g /x\ : k. By assumption. 

Case IAQVarC Annot: 


E; Rel(^) ^ s w u H Qi 
k < a t H fl 2 

E; fit] (a :: s) : a : u; x.tx H fb, fl 2 


IAQVarC _ Annot 


Given E; 4/ by r 0 : k, we must show E; 4/, Qi, fi 2 by (t x)[to/x] : cr, which can be 
rewritten to E; 4/, fb, fl 2 by rr 0 : a. We know E btx 4/ ok by Lemma E.8. The 
induction hypothesis then tells us E; Rel(4/, fix) b y a : Type. Lemma E.17 tells 
us E; Rel(4>) by k : Type. We can thus use Lemma E.41 to get E; 4/, fb, fl 2 by t : 
IIxiReiK. cr. Rule Ty_AppRel gives us E; \R, fb, fi 2 I tt 0 : <t[to/x], but Lemma 
E.ll tells us that the substitution in the kind has no effect. We are done. 


□ 

Lemma E.43 (Declarations). If E btx T ok and E;T ^ ec i decl x : k := r, then 
dom(decl) = x and E; T by t : k . 

Proof. By case analysis on the type inference judgment. 


Case IDecl Synthesize: 


E;Tl^t~^T:«;HD 
E;T^| V Q -w A;0 

t' = AA. (r[Q]) k! = IJinfA. («[0]) 

E; T b^ed x := t x : k' := r' 


IDecl_Synthesize 


By Lemma E.3, we have E btx T ok. We then use Lemma E.42 to get E; T, fl by 
t : k. Lemma E.8 gives us E btx T, fl ok. Property E.24 tells us that 0 is 
idempotent, that E btx T. A ok, and that E; T, A b 0 : fb Lemma E.9 gives us 
E; T, A, Q by t : k. We can then use Lemma E.23 to get E; T, A by t[0] : k[ 0]. 
Rule Ty_Lam (used repeatedly) gives us E;T by T> '■ «'• Lemma E.3 gives 
E; T by t' : k' as desired. 
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Case IDecl Check: 


S; s (t H Oj 

E; Rel(r) Rel(fV) ^ A i; ©! 

a' = n^X©!]) 

S; T 1^ t : a' -w r H 0 2 
E; T fl 2 -w 0; 0 2 

t' = t[© 2 ] _ 

E; T fr ec i x :: s := t ** x : a' := r' 


IDecl_Check 


Lemma E.3 provides E ^ tx T ok. We then use Lemma E.42 to get E; Rel(r, fb) h|, 
a : Type. Lemma E.8 gives us E ^ tx Rel(r,fii) ok. Property E.24 tells us ©i 
is idempotent, E ^ tx Rel(r),Ai ok, and E;Rel(r),Ai ^ ©i : Rel(fii). Lemma 
E.9 gives us E; Rel(T), Ai, Rel(Qi) hj y a : Type. Lemma E.23 then says that 
E; Rel(r), Ax ^ cr[©i] : Type. Lemma C.6 gives us E; Rel(r), Rel(Ai) hf y cr[@i] : 
Type and thus we can use Ty_Pi repeatedly to get E; Rel(r) ^ a' : Type. 
A second use of Lemma E.42 gives us E; T, 0 2 Ny t '■ cr'. A second use of 
Property E.24 tells us 0 2 is idempotent and E; T ^ 0 2 : 0 2 . We can thus use 
Lemma E.23 once again to tell us E; T r[0 2 ] : cr'[0 2 ], except that Lemma E.ll 
tells us that zonking the kind has no effect. Thus E; T hf y r' : cr', and Lemma E.3 
gives us E; T hfy t' : cr' as desired. 


□ 


Theorem E.44 (Full program elaboration is sound). If E htx P ok and E: Y \~^ mg 
prog r'; 9, then: 

1 . E btx T, P' ok 

2. E; T bubst 0 : P' 

3. dom(prog) C dom(r / ) 

Proof. By induction on the type inference judgment. 

Case IProg_Nil: Trivial. 

Case IProg Decl: 


E; T freci decl x : n r 
E; T, x: Re \ k, c:x ~ r ^ rog prog T'; 0 
St r f^-og decl; prog x: Re \n, c:x ~ r, F'; (t/x, (t)/ c) o 9 


IProg_Decl 


Lemma E.43 tells us that x = dom(decl) and E; T by r : k . We must show 
E ^ tx r,x:ReiK, c:x ~ r ok. To do this, we need only E; Rel(r) hj y k : Type, 
which we get from Lemma C.43. We can then use the induction hypothesis 
to get E f^ tx r, x: Re \n, c:x ~ r, T' ok, E; T, x: Re \n, c:x ~ t fi ubs t 0 : P', and 
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dom(prog) C dom(r'). We already have that the outgoing context is well-formed 
and the domain condition. We need only show that E; T h ubst ( t/x,(t)/c ) o 
9 : x: Re \n, c:x ~ r, T'. Let 9' = (r/x,(r)/c) o 9. We will work backwards. 
The last step will be Subst_TyRel. We must show E; T ht y x[9'] : k and 
E; T hj ubst O' : (c:x ~ r, Y')[t/x\. We have already established the former (noting 
that x[9'] — t). We rewrite the latter as E;T li ubst 9' : c:r ~ t,T'[t/x]. This 
will be shown by Subst_Co. We must then show E; Rel(r) 1^ 0 c[9'] : r ~ r and 
E;T bu bst O' : Y'[t/x][{t)/ c}. The former is straightforwardly by Co_Refl and 
Lemma C.6. For the latter, recall that we know E; T, x: Re \K, c:x ~ r li ubst 9 : T'. 
Thus, two uses of Lemma E.29 gives us E; T ii ubst 9' : r'[r/a;][(T)/c] as desired. 
We are done. 


□ 


E.10 Conservativity with respect to OUTSIDElN 


This section assumes the introduction to Section 6.8.2, where much of the conser¬ 
vativity argument is given. 

Claim E.45 (Expressions). If T t : k -w Q w under axiom set Q and signature 
E ; then E; T, encode(Q) t • : k H a:i rre |Type, encode((5w) where a = fuv(«;) U 
fuv(Qw)- 

Proof sketch. Case VarCon: OutsideIn fully instantiates all variables, producing 
unification variables for any quantified type variables and emitting wanted 
constraints for any constraint in the variable’s type. Bake does the same, via 
its kbt judgment. 

Case App: In this case, t = ti t 2 . OutsideIn’s is a fairly typicaly application form 
rule, but using constraints to assert that the type of ti is indeed a function. 
Bake works similarly, using its h^ n judgment to assert that a type is a n-type. 
Of course, OutsideIn’s treatment of t 2 uses synthesis while Bake’s uses its 
checking judgment. 

Case Abs: This rule coresponds quite closely to Bake’s ITy_Lam rule. Note that 
OutsideIn does not permit annotations on A-bound variables, simplifying 
the treatment of abstractions. Furthermore, Bake must use its generalization 
judgment (written with M-) to handle its unification variables, while OutsideIn 
does not need to have this complication. 
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Case Case: Contrast OutsideIn’s rule with Bake’s: 


rbeiT-^C 1 /?, 7 fresh 
Ki'.Wabi.Qi => Vi —>• Ta Afresh 

T, (x*:[a Fa 7]^) h ej : 7 C 5 * = fuv(ji, C*) — fuv (r, 7 ) 
c , _ f Ci A Ti~ 13 if fej = e and Qi = e 

* \ -d,-.([a i-f 7 ]^, Z> (7, A Tj ~ /?) otherwise 

T h- case e of {fQzj -A e*} : /? C A (T 7 ~ r) A (/\ C-) 


£3; ^ t 0 7o_: k 0 H ^0 

E; \l/, fl 0 ferut alt; k 0 7; A; if'; r H fl' 0 

fresher Q' = Q 0 , ^ 0 , ct:i rre |Type 

Vi, E; \l/, Q'; TIA. ff' r; r 0 > 7 lift alt; : cr alti H fb 

alt = make exhaustive(a/i; /c) 

- ---——--- ITy_Case 

E; \l/ case t 0 of alt case a (r 0 > 7) of alt :aH f V, fl 


E hfc if : Ai; A 2 ; ff' A 3 , A 4 = A 2 [r/dom(A 1 )] 
dom(A 3 ) = x dom(A 4 ) = dom(A') 
match {dom( A 3)} (types(A 4 ); types(A')) = Just# 
E;^,A 3 ^t:K-wTHO 
O^As^O';^ 

A' 3 = A 3 , c:t 0 ~ if{r} x 

E; T; HA'. ff'r;T 0 Hx -A t : « H -A AA' 3 . (r[f]) H ft' 


IAlt_Con 


The first premises line up well, with both checking the scrutinee. Both rules 
then must ensure that the scrutinee’s type is headed by a type constant (T 
in OutsideIn, if in Bake). This is done via the emission of a constraint in 
OutsideIn (the T7 ~ t constraint in the conclusion) and the use of kemt in 
Bake. One reason for a difference in treatment here is that Bake wishes to 
use any information available because of the existence of its checking judgment, 
whereas OutsideIn is free to invent new, uninformative unification variables 
(7). This difference makes Bake produce the unification variables only when 
the scrutinee’s type (k 0 ) is not already manifestly the right shape. 


Both rules then check the individual alternatives, which have to look up the 
constructor (fQ and if, respectively) in the environment. PlCO gathers the 
three sorts of existentials together in A 2 ; OutsideIn expands this out to the 
hi, Qi, and v % . OutsideIn does not permit unsaturated matching, so we can 
treat A 4 as empty. OutsideIn does not consider scoped type variables; it thus 
only brings in of types v l while checking each alternative; Bake brings all 
of A 3 into scope. OutsideIn checks the synthesized type of each alternative, 
Ti against the overall result type /3; Bake ensures the types of the alternatives 
line up by using a checking judgment against the result kind k. (Note that, like 
OutsideIn, this result kind is a unification variable. We can see that the k in 






IAlt_Con is the a from ITy_Case.) 

The constraint C[ emitted by OutsideIn is delicately constructed. If there are 
no existential type variables and no local constraints, OutsideIn emits a simple 
constraint. Otherwise, it has to emit an implication constraint. OutsideIn’s 
implication constraints allow unification variables to be local to a certain con¬ 
straint; the treatment of implication constraints is somewhat different than 
that of simple constraints. In particular, when solving an implication constraint, 
any unification variables that arose outside of that implication are considered 
untouchable—they cannot then be unified. (See Section 6.3.3.) In order to avoid 
imposing the untouchability restriction, OutsideIn makes a simple constraint 
when possible. Due to Bake’s more uniform treatment of implications, this 
distinction is not necessary; untouchability is informed by the order of unification 
variables in the context passed to the solver. 

Bake makes its version of implication constraints via the generalization judgment 
(written with ^a). All of the constraints generated while checking the alternative 
are quantified over variables in A 3 ; this precisely corresponds to the apapearance 
of the Qi to the left of the D in OutsideIn’s constraint C[. (Recall that Qi is a 
component of Bake’s A 3 .) Bake also adds another equality assumption into 
its A 3 ; this equality has to do with dependent pattern matching (Section 4.3.3) 
and has no place in the non-dependent language of OutsideIn. 

Case Let: Other than Bake’s generalization step, these rules line up perfectly. 

Cases LetA and GLetA: These cases cover annotated lets, where the bound 
variable is also given a type. I do not consider this form separately, instead 
preferring to use the checking judgments to handle this case. 

□ 


E.ll Conservativity with respect to System SB 

This section compares Bake with System SB, as presented by Eisenberg et al. [33, 
Figure 8]. Omitted elaborations are denoted with •. Please refer to the introduction to 
Section 6.8.3 for changes needed to both System SB and Bake in order to prove the 
following claims. 

Claim E.46 (System SB Subsumption). If k i <dsk ft 2 , then fti < ft 2 • H fb 

Proof sketch. Note that this refers to the judgment in Eisenberg et al. [33, bottom 
of Figure 9]. If we assume all relevances are Rel, the rules of the Bake subsumption 
judgments are identical to those of the SB judgments. The one exception is the 
comparison between DSK_Refl and ISub_Unify, where Bake emits an equality 
constraint instead of simply asserting that the two types are equal. This variance is 
addressed by the tweaks above, and thus we are done. □ 
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Claim E.47 (Conservativity with respect to System SB). Assume « T. 

1. If T t => k, then E; t • : k H Q. 

2. If T b t t/ien S;f l|tv».:/cSn. 

3. If T fi b t -<= t/ien S;$^t:K^»Hfi. 

If T ff b t -£= t/ien S; ^ t : ac • H f2. 

Proof sketch. By induction on the input derivation. This remains only a proof sketch 

because I have not concretely defined the tweaks above, nor have I given a full 

accounting of how types written in SB source are checked to become PlCO types. 

Case SB_Abs: We know here that t = Ax.t 0 , ac = n Req 3;:ReiQ;. Av 2 , and that 
r,x:ReiO! t 0 => K 2 - We will use ITy_Lam. By IQVar_Req and IAQ- 
Var_Var, we can see that E; T x : a; Req H a:i rre |Type. The induction 

hypothesis tells us that E; \l/, a:| rre |Type, rciReio; lj| t 0 • : ac 2 H Q. We can thus 
use ITy_Lam to get E;T Ax.t 0 • : n Req a;:ReiQ;. k 2 H a:i rre |Type, Q. We 
then must use ITy_Inst to remove the star from the judgment; however, given 
that the kind starts with a visible binder, instantiation has no effect, and we are 
thus done. 

Case SB_InstS: By ITy_Inst, noting that Bake’s instantiation operation fast 
behaves exactly like the manual instantation in SB_InstS’s conclusion. 

Case SB_Var: By ITy_Var. 

Case SB_App: By ITy_App, noting that all visible quantification in System SB 
is relevant, and thus the fj^ g judgment reduces to 

Case SB_TApp: By ITy_AppSpec. 

Case SB_Annot: Here, we know t = (A@a.t 0 ) :: s 0 where E; ^ 

s 0 /t H fii and k = n Sp ec a: in-ei Type, 6:| rre |Type. ac 0 . Furthermore, 
we know T, a:| rre |Type ly b t 0 ■$= ac 0 . The induction hypothesis tells us 
E; 'F, a:i rre |Type, $6:i rre |Type t 0 : k 0 • H fi 2 - We wish to use ITyC_Skol 
( repeatedly) to get from that last judgment to E; \k, a:i rre |Type t 0 : 
ns P ec$^ ; irreiType. ac 0 • H 0 3 . Rename $b to b. We now wish to use 
ITyC_LamInvisIrrel (repeatedly). Consider one use. We can see that 
E;\F ^ a : Type a : Type; a;.£ H 0 . We know E; \k, a:| rre |Type 
t 0 : n S pec&:irreiType. ac 0 C fi 3 and can thus conclude E; T A@o.t 0 : 
fjspec® • irreiType, &:| rre |Type. ac 0 • H O 4 . Repeat this process to get E; 

A@a. t 0 : n S pe C a:irreiType, 6:, rre |Type. «o • H f2 5 . This can be rewritten as 
E; lj| A @a. t 0 : k ■ H fi 5 . Thus ITy_Annot gives us E; lj| (A@a. t 0 ) :: 
s 0 • : k H fl 6 as desired. 

Case SB_Let: By ITy_Let. 
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Case SB_DLet: By ITyC_Let. Note that System SB’s decision to put 
SB_DLet in the unstarred judgment is immaterial, as pointed out by Eisenberg 
et al. [33, footnote 13]. 

Case SB_DAbs: By ITyC_Lam. 

Case SB_Infer: By ITyC_Infer and Claim E.46. 

Case SB_DeepSkol: Recall that according to the tweaks I have made to this al¬ 
gorithm, this rule now does shallow skolemization. We are done by ITyC_Skol. 

□ 
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Appendix F 

Proofs about PlCO= 


F.l The PlCO - type system 


The PlCO - system is introduced in Section 7.2; its rules, in full, are as follows: 


n=r[ 


alt = alt/\ 



DEProp 


0 = 0 


r = t' 

7T —)■ T = 7T —y T 1 


DE_Alt 


- DE VecNil 

0 = 0 


I = 


r 


T = t' 0 = 0 

T, 0 = r', 0 
r = r r 0 = 0 

0 = 0 
7,0 = 7 ; , 0 


DE_VecTyRel 


DE_VecTyIrrel 


DE_VecCo 
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DE CtxNil 


k = k 


I' = I v 


a: p K, T = a: p K', T' 

(f) = $ r = r 

c:0,r = c\<P,T' 


DE_CtxTy 


I E; T Ihty r : ac | Type formation 
E l^ tx r ok 


a:Rei« e r 


E htc H : Ai; A 2 ; H' E l^ tx T ok 
E; Rel(r) lb ec t : Rel(Ai) 

E; T Ihfy % } : , n(A 2 [r/dom(A 1 )]). H 1 r 


E; T Ihty t i : K 0 
E; T Ihty t 2 : 


k 0 = na: R eiKi. ft 2 
«i = k[ 


E; r Ihty tit 2 : ft 2 [T 2 /a] 

E; r Ihty T\ : K 0 K 0 = naiirrel^l. k 2 

E; Rel(r) Ihty r 2 : k[ ki = ^ 

E; r Ihty Ti{t 2 } : R 2 [T 2 /a] 


DTy_AppRel 


DTy AppIrrel 


E; T Ihty t : Ro Ro = If c:(j). h 
E; Rel(T) Ife, 7 : <t>' <t> = <t>' 


E; T llty T 7 : refy/c] 

E-,T,Re\(8)\ky k:t t = Type 

E; T Ihty IW. k : Type 

E; Rel(T) ll^ 0 7 : % ~ k 2 

E; T l^y r : k\ E; Rel(T) lht y k 2 : a 

K\ = a = Type 

E; T llty r > 7 : k 2 


DTy_CApp 


DTy_Cast 
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E; Rel(r) I ky k : t 0 t 0 = Type E; T lb 
a =T1A. Ha 
E; Rel(r) II* Ha : n 
n = Type 

Vi, EjiyriA. crl£ lt alti : k 
alt are exhaustive and distinct for H, (w.r.t. E) 
E; T Ik, case K rof alt : /c 


E; T Ik, A5. r : lid./ 


E; T Ihty t : IlaiReiKi. 

E; T Ihty fixT : k 

E; Rel(r) II* 7 : ~ 

E; Rel(r) lht y r : k k = Type 

E; T Ihty absurd 7 r : r 
I E; T; a IF, t alt : k I Case alternatives 


DTy Absurd 


E k c H : Ai; A 2 ; A 3 , A 4 = A 2 [o : /dom(A 1 )] 

dom(A 4 ) = dom(A') 

match{ dom (A 3 )}(types(A 4 ); types(A')) = Just# 

E; T Ihty t : Kq Kq = HA 3 , c:t 0 ~ H^y dom(A 3 ). t 
E: Y: 'II A'. H'a IFC H ^ t : k 


DAlt Match 


E; T Ihty t : k' 

ST; a !!?*_-> 

I E; r ll^ 0 7 : (b\ Coercion formation 


DAlt Default 


E;T llco (t) : t 
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E; T Ito 72 : r' r 3 


E;T l^o 7 ! : f| Kl ~ K2 r 2 

T 2 = T 2 K 2 = «2 

E; T ll^o 7i 9 72 : Ti ~ t 3 


DCo_Trans 


E;T Ife, rj : k x ~ k 2 |tiJ = |t 2 J 
E; T lht y n : k[ E; T 11 ^ t 2 : k ' 2 

Kl ~ ~ - DCo_Coherence 

E; T l^o n t 2 : Ti ~ t 2 


Vi, E; T ll^o 7 j : ^ 
E; T lhty #{<t} : «i 


DCo_Con 


E; T ll^o 7 i : ri ~ r 2 

E; T ll ^ 0 7 2 : (Ti ~ cr 2 

E; T lhty T\ <7 1 : aci E; T lhty t 2 <t 2 : k 2 

E; T Ife, 7i 72 : n <Ti <v t 2 a 2 


DCo_AppRel 


E; T Ife, 7 i : ri ~ r 2 
E;T ll ^ 0 72 : ai ~ cr 2 

E;T lhty Ti {cri} : TCi E; T l^ y t 2 {cr 2 } : k 2 
E; T Ife, 7i {72} : 17 {ai} ~ t 2 {a 2 } 


DCo_AppIrrel 


E; T ll ^ 0 70 : ri ~ t 2 

E;T lhty 1771 : ** E; T lht y t 2 7 2 : 

-- 7 -r--- DCo_CApp 

E: T ll ^ 0 70 ( 71 , 72 ) : Ti 71 ~ t 2 72 


E; T Ik, 77 : Kl T yp e ~ T yp e K2 

_ E; r, aiRei^! I^o 7 Type - Type ^2 _ 

E;T ll ^ 0 Ua: p r 7.7 : (I\.a\ p K\. a\) ~ (II a\ p K 2 . (cr 2 [a > symry/a])) 


DCo_PiTy 


E; T ll^ 0 771 : Ti ~ r 2 E; T ll^ 0 772 : 07 ~ cr 2 
E; T, c:n ~ a! I to 7 : « x T yP e ~ T yP e c # 7 

773 = 771 1 c 5 sym 772 

E;T Ife, lie: (771,772). 7 : (IIc:ti ~ 01./C1) ~ (nc:T 2 ~ cx 2 . (k 2 [W c D) 


DCo_PiCo 
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E; T ll^o rj : ~ k 2 E; T ll^ 0 70 : 77 ~ r 2 

Vi, E; T l ^ 0 7i : <Jj ~ <7' 

alt 1 = 7fj —)■ 07 a/t 2 = 7Tj —)■ a' 

E; r Ihfy case Kl Ti of alt 1 : «7 E; T 11 ^, case K2 t 2 of a/t 2 : tc 2 
E; T ll^ 0 case,, 70 of Trpipp# : case K1 77 of alti ~ case K2 t 2 of alt 2 


DCo_Case 


E; r l^ 0 77 : K\ ~ k 2 
E;T, a: p Ki ll^ 0 7 : 77 ~ r 2 
E; T, a\ p Ki Ihfy 77 : 07 E; T, a\ p Ki lht y t 2 : cr 2 
E; T ll^o A a: p rj. 7 : Aa:^. 77 ~ \a\ p n 2 . (r 2 [a > sym^/a]) 


DCo_Lam 


E; T ll^o 771 : Ti ~ r 2 E; T ll^ 0 rj 2 : 07 ~ 07 
E; T, c:ti ~ 07 lta> 7 : ~ c # 7 

773 = Vi 9 c 5 sym 772 

E; T ll^o Ac:(771,772). 7 : (Ac:ti ~ 07. « a ) ~ (Ac:t 2 ~ 07. (k 2 [W c D) 


DCo_CLam 


E; T ll^o 7 : ri ~ r 2 

E; T lhty fixri : 7Ci E; T Ht y fixr 2 : n 2 
E; T lh^ 0 fix 7 : fix 77 ~ fix t 2 


DCo_Fix 


E; T lh co 7l : H 1{Tl} ^ ~ & ifj ^ H{ 

E; T lh co 72 : H 2{n} 7/7 - ' {n j ^ H 2 ^ H> 

E; r l^o 77 : «7 T1 ~ T2 k 2 77 = Type r 2 = Type 

E; T H77 absurd (71,72) 77 : absurd 71 tci ~ absurd 72 k 2 


DCo_Absurd 


E; r l^o 7 : n ~ 72 

Ti = IlaipRi. 07 r 2 = na: p R 2 - cr 2 

E; T ll ^ 0 argk 7 : K\ ~ k 2 


DCo_ArgK 


E; T ll^ 0 7 : Ki ~ k 2 

Ri = IIc:(ti ~ t[). <j 1 r 2 = lie:(77 ~ T2). 07 

E; r IIe 0 argk, 7 : 77 ~ t 2 


DCo_CArgK 1 


E; r l^ 0 7 : «7 ~ k 2 

Ri = IIc:(ti ~ t[). <j 1 k 2 = IIc:(t2 ~ T2). 07 
E; T lh^ 0 argk 2 7 : r-f ~ T2 


DCo_CArgK 2 
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DCo_ArgKLam 


E; T ll^o 7 : ri ~ r 2 
t i = Aa: p «i. (Ti t 2 = Xa: p K 2 . <J 2 

E; r lfj 0 argk7 : Ki ~ k 2 


E; r Ik, 7 : ~ k 2 

«i = Ac:(ti ~ t(). Ui r 2 = Ac:(t 2 ~ t' 2 ). a 2 
E; T ll^o argk x 7 : 77 ~ t 2 


DCo_CArgKLam1 


E; r l^o 7 : Ri ~ k 2 

Ki = Ac:(ti ~ t(). Ui r 2 = Ac:(t 2 ~ t 2 ). cr 2 
E; T ll^o argk 2 7 : t[ ~ t 2 


DCo_CArgKLam2 


E;T IIbo 7 : 0 |Ai| = |A 2 | = n 
0 = HAi. t1 ~ HA 2 . t 2 
E; T llty n : 07 <J\ = Type 

E; T llty r 2 : cr 2 cr 2 = Type 

E; T ll^ 0 res n 7 : 77 ~ r 2 


DCo_Res 


E;T 1^7: 0 | At | = |A 2 | = n 

0 = AAi. 77 ~ AA 2 . t 2 
E; r llty Ti : Ri E; r llty t 2 : r 2 
E; T llj 0 res 71 7 : 77 ~ r 2 


DCo_ResLam 


E; T l^ 0 7 : 0! 

01 = IlaiReiRi. 07 ~ na: Re |R2- 02 
E; r ll^ 0 77 : 77 K 'i ~ K 2 r 2 
«7 = k' l k 2 = k' 2 

E; r ll^ 0 7@r7 : 07(77/ a] ~ cr 2 [T 2 /a] 


DCo_InstRel 


E; r Ifeo 7 : 0 i 

0i = IIa:| rr eiRi. 07 ~ IIa:| rr eiR 2 . 07 
E; r ll^ 0 77 : Ti K i~ re 2 T2 
= ^2 

E; T llco 7@{r?} : o’lfTi/a] ~ cr 2 [T 2 /a] 


DCo_InstIrrel 
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E; T ll^o 771 : 0 3 
0 3 = He: fa. <T 1 ~ IIc: 02 - o 2 
EjrlbTn^ 0 ! = 0 ; 


E; T ll^o 72 : (f )' 2 


0 2 = 02 


E; T ll^o 77i@(7i,7 2 ) : Oifa/c] ~ cr 2 [ 7 2 /c] 


DCo CInst 


E; T l^ 0 7 : 0 i 

0 i = Aa: Re |Ki.Ti ~ \a: Re \K 2 .T2 

E; r Ife, 77 : (j 1 k 'i~ k 2 (j 2 Kl = ^ , 

E; T ll^o 7@77 : Ti[ai/a] ~ T 2 [a 2 /a] 


DCo InstLamRel 


E; r Ha, 7 : 0 i 

01 = Aa.| rre |Ri. El Aci.| rre |7C2- ^2 

E; r 1^0 77 : Ui ,j 2 Kl = tc 2 = k 2 

E; r llco 7 @{ 77 > : nfa/a] ~ T 2 [cr 2 /a] 


DCo InstLamIrrel 


E; r Ha, 7 : fa 
03 = Xc:fa. Ui ~ Ac:02 - 02 
E;T l^o 771 : 0 ; fa = fax 

E; r ll^o 772 : 02 02 = 02 


E;T IIbo 7 @(? 7 i, rj 2 ) : Oifa/c] ~ o 2 [t 7 2 /c] 

E; T llco 7 : 0 

0 =^ 0 -%^# 

Ipi — T fa 

— a 

E; T Ihty t : Ki 

E; T Ihty a : k 2 

E; T ll« 

, nth* 7 : t ~ a 

E; T l ^ 0 7 : 0 

ofan {h . } v~ f I W} fa 

0 * = M 0 

J = M 

E; Rel(r) 1 k y t : Kl 

E; Rel(r) lh^ cr : ac 2 

E; T lh co 

nthj 7 : t ~ a 


DCo CInstLam 


DCo_NthRel 


DCo NthIrrel 
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DCo_Left 


E; T llf 0 7 : 0 

0 = Ti_0i ~ T 2 _02 

E; T lht y Ti : h 0 h 0 = TC^i. Hi 

E; T Ihfy t 2 : k'q h' 0 = TK 2 . h 2 

E; r ll^ 0 77 : 0' 

0' = ’n<5i. Ki ~ TP> 2 . h 2 

E; T llf 0 left,, 7 : Ti ~ t 2 


E; T IIbo 7 : 0 
0 = Ti_(Ti ~ T 2 J7 2 

E; T lhty o - 1 : Hi E; T lht y a 2 : k 2 
E; T\\- co ri: 0 ' 0 ' = Hi ~ k 2 

E; T lhf 0 right, ? 7 : 01 ~ <r 2 


DCo_RightRel 


E; T llco 7 : 0 

0 ^ Ti_{0-l} ~ T 2 _{CT 2 } 

E; T Ihfy 0\ : Hi E; T Ihfy cr 2 : k 2 
E; r llf 0 rj : 0 ' 0 ' = K\ ~ k 2 

E; T llf 0 right^ 7 : 07 ~ cr 2 


DCo_RightIrrel 


E; r llf 0 7 : t 1 r 2 

E; T lhf 0 kind 7 : % ~ k 2 


DCo_Kind 


E; T llty t : k E; T l^ y r' : re' 
E; F % t —r' 

E; T lhf 0 stepr : r ~ r' 


E; T Ihp rop 0 ok Proposition formation 


re = re' 


DCo_Step 


E; r Ibec 0 : a] 


E; T lhf y Ti : Hi 
E; T Ihfy r 2 : re 2 

E; T I hprop Ti K1 ~ K2 T 2 ok 

Type vector formation 


DProp_Equality 


E llf tx r ok 
E; T IUc 0 : 0 


DVec_Nil 
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DVec_TyRel 


E; T lljy t : k ' k = k ' 

E;T Ibec^: A[r/a] 

E; T IK/ ec T r 0 : a: Re |R, A 

E; Rel(r) IIq, t : k' k = n' 
E;T Ibec^: A[t/o] 

E; r IK/ec {t}, 0 : a ; lrrel^, A 

E; Rel(r)Jco 7 : # 0 = 0' 

E; T Ih^ec 0 : A[ 7 /c] 

E; T IK>ec 7, 0 : c: 0, A 

I E ll^ T ok I Context formation 


DVec_TyIrrel 


E;Rel(r) l^ y r : r r = Type 
a # T E It* T ok 


E ll^ T, a\ p K ok 

E; Rel(r) lh prop 0 ok c # T E It* T ok 
E It* T, c:0 ok 

I E; r It a —> a' I Small-step operational semantics 


DCtx TyVar 


DCtx CoVar 


E; T It (\a: Re \K.ai)a 2 —> o x [a 2 /a] 


DS BetaRel 


E; T It (Aa:i rre |R. ui) {a 2 } —* V][a 2 /a] 


DS BetaIrrel 


E; T It (Ac:0. a) 7 —» cr[ 7 /c] 
alti = H —> To 

E; r It case K H{ T y 0 °f alt — > To 0 (> 0} 

alti = _ — >• cr no alternative in alt matches H 

E; T It case K H{w} "0 of alt —» cr 


DS Default 
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alti = —y (J no alternative in alt matches H 

E; T lli case K II m i/j > 7 of alt —> a 


DS_DefaultCo 


T = \a-.Re\K. a 
E; T lh fix r —)• cr[fixr/a] 


DS_Unroll 


E; r lli (v > 7i) > 72 — y V > (715 72) 
E; T, a\\ rre \K lli a —> a' 


E; T lli Xa:\ ne \K. a —> Xa: ine \K. a ' 
E;r lli cr — 


D S _ Irrel Abs _ Cong 


E; T lli <7-0 —y a' i/j 

EjTl^a —y a' 

E; T lli a > 7 —y a 1 > 7 

E; T lli cr—> cr' 


DS App Cong 


DS_Cast_Cong 


E; T lli case T a of alt —y case T a' of alt 


DS Case Cong 


E; T lli t - 


DS Fix Cong 


E; Rel(r) Ife, 7o : cj> 

4> = Ila:R e \K. a ~ IlaiReiKC a ' 

71 = sym(argk7o) 72 = 7 o@(t > 71 ^ sym7l r ) 

E; r lli (if > 70) t —y v (t > 71) > 72 


DS_PushRel 


E; Rel(r) Ife, 7o : <j> 

4> = ria:| rr eiK. a ~ na:| rre |K'. cr' 

71 = sym(argk7o) 72 = 7o@(t > 71 ~sym 71 r ) 

E; r lli (v > 70) {r} —y v {r > 71} > 72 


DS_PushIrrel 
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DS_CPush 


E; Rel(r) lh co 7 q : 0 O 

0o = IIc:0. cr ~ nc:0'. cr' 

7 i = ar S k i 7 o 72 = argk 2 7o 

V = 719 77 9 sym7 2 73 = 7 q@(t/, 77) 

E; T lli (v > 70 ) 77 —)• v 77' > 73 


7 l = Oa:| rre |(/c). 7 72 = 7l ~(Type) t 2 

Ti = na:| rre |fv. (Ki[a>sym(ft)/a]) t 2 = na:i rre iK. «i 

E; T lli Aa:i rre iK. (u > 7 ) —*• (Aa:i rre |K. v) > (71 ° 9 72 ) 


DS_APush 


71 = 7 o@(a ~ 72 a > 72) 9 sym7 2 

72 j= argk 7 o 

E; T lli fix ((Aa: Re |/c. cr) > 70 ) —> (fix (Aa: Re |/c. (cr > 71 ))) > 72 


DS_FPush 


Ehtc H : a: hre \K; A; H' A = Ai,A 2 n = |A 2 | 
rc = Tla:\ rre \K, A. H'a 
a = Tf(A 2 [r/a][ 0 /dom(Ai)]). H't 
cr' = Tt(A 2 [T'/a][ 0 / /dom(Ai)]). id'r' 

E; Rel(r) Ife, 77 : 0 0 = a ~ a' 

E; Rel(r) I 0 ec t' : a: Re iK 

Vi, 7, = build_kpush_co({/«)@(nths (res n 77)); 0 X j_^| 
Vi, - 0 ' = cast_kpush_arg( 0 j; 70 
H —> tc' E alt 

E; T lli case Ko (iJ^ 0 ) > 77 of alt —>■ case Ko 0 of alt 


DS_KPush 


F.2 Properties of = 

Section 7.2 stated some properties of = somewhat informally. Here are the more formal 
descriptions: 

Property F.l (Formal statement of Property 7.3). //EjT r : k, E;T ht y r' : n, 
and t = t', then there exists 7 such that E; Rel(r) hi 0 7 : r ~ t'. 

Property F.2 (Formal statement of Property 7.4). J/0 = 0 ; , then t[0/z] = r[0')%]. 

Lemma F.3 (Transporting coercions). //E; Rel(r) hi 0 7 : 0, E; Rel(r) ^ rop 0' ok, arid 
0 = 0 ' 7 then there exists 7 ' such that E; Rel(r) hi 0 7 ' : 0'. 
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r 2 and 


Proof. Lemma C .44 tells us that E; Rel(r) ^ rop <t> ok. Let (j) — T\ K1 ~ K2 
ft = t[ k i~ k 2 7-'. We can conclude all of the following by inversion: 

• E; Rel(r) by n : K\ 

• E; Rel(r) by t 2 : k 2 

• E; Rel(r) r[ : k\ 

• E; Rel(r) by t' 2 : ft 

• T 1 = t[ 

• t 2 = 

By Property F.l, we can get 71 and j 2 such that E; Rel(r) ly 0 71 : T\ ~ r[ and 
E; Rel(r) 7 2 : t 2 ~ r^. Thus, E; Rel(r) sym7!, 7,7 2 : as desired. □ 

We also regularly need to extract certain bits of a type or proposition, via an 
extraction operator =. Extraction has these properties: 

Property F .4 (Extraction respects =). 

1 . If t = t' then t = t' . 

2 . If (j) = (j)' then (j) = (ft. 

Property F .5 (Extraction can be chained with =). 

1 . If t = t' and t' = r", then r = t" . 

2 . If 4 >= (ft and ft = ft', then (f> = ft'. 

Property F.6 (Extraction is deterministic). 

1 . If t = ri and t = t 2 , then T\ = r 2 . 

2 . If 4 > = ft and f> = ft, then ft = ft. 

Property F .7 (Extraction is well-typed). 

1 . If E; T ht y t : k and r = t' , then E; T t' : k' 

2 . If E; T h^rop (j) ok and (j) = ft, then E; T h^ rop ft ok. 
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F.3 Lemmas adapted from Appendix C 

Lemma F.8 (Scoping), (as Lemma C.12, but with reference to lb judgments) 

Proof. Similar to the proof for Lemma C.12. □ 

Lemma F.9 (Context regularity). If: 

1. E; T Ihfy t : k, OR 

2. E; r Ife, 7 : </>, OR 

3. E; r Ifprop f ok, OR 

4- E; T; cr 0 Hf° t alt : k, OR 

5. E; T IUc OR 

6. E Ife* T ok 

Then E Ibtx prefix(r) ok and b^j g E ok, where prefix(r) is an arbitrary prefix of F. 
Furthermore, both resulting derivations are no larger than the input derivations. 

Proof. Straightforward mutual induction. □ 

F.4 Soundness of PlCO= 

The following lemma also defines the |•] operation. This deterministic operation is 
defined to be the existentially-quantified output of the clauses of the following lemma, 
as labeled. Note that making sense of [•] requires that the argument be well-formed 
(that is, the premises of the clause defining the operation must be satisfied). For 
example, jY) is not just an operation over a type r, but it also requires E; Y by t ■ k 
as an input. 

Lemma F.10 (PlCO s is sound). The uses of |T~| below depend on Lemma F.9 
above. 

1. If E I'btx r ok, then E btx T' ok where T 1 2 3 * 5 6 7 = T. Let |T] = T'. Furthermore, 
Rel((T]) = [Rel(r)] and if T = r 0 ,<S, then [T] = 

2. If E; T lb y r : k, then E; |T] by t' : k! where t' =: r and k' = k. Let [t] = t'. 

3. If E; T Ibo 7 : (j), then E; [T] bo l' '■ <t>' where (j) = 4>'. 

4 ■ If S; T; a llf| t alt : k and we have t' and k' such that r 1 = r and k' = k, then 
E; |T];cr b !t alt 1 : k' where alt 1 = alt. Let \alf] = alt'. 

5. If E; T Ifprop 4> ok, then E; |T] brop 4>' where <f> = 4>. Let [<fi\ = <f>. 

6. If E; T Ibec ■ A, then E; |T] bee ■ A where if' = if. Let [V'l — ■ 

7. If E; T lb cr —> r, E; Tiby a : k, and E; V lby t : k, then E; \T] b \tr] — \t] . 
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Proof. By induction on the typing derivations. 

Case DCtx_Nil: Immediate. 

Case DCtx TyVar: 


E; Rel(r) lit y k:t t = Type 
a # r e lieu r ok 


E lh tx T, a: p K ok 


DCtx_TyVar 


We must show E btx |T], a\ p \P ok for some k! = k. Note that |T] is well-formed 
by the induction hypothesis. The induction hypothesis gives us [k] such that 
E; Rel([r]) b y [/c] : t' such that t' = r. By transitivity of = (Property 7.1), t' = 
Type. We have E; Rel((T]) by r' : Type (by Lemma C.43) and E; Rel(|T]) by 
Type : Type (by Lemma C.38 and Lemma C.10). We then use Property F.l to 
get 7 such that E; Rel((T]) bo 7 : r' ~ Type. Choose k' = [/c] >7. We see that 
E; Rel([P]) by \k] > 7 : Type as desired. Property 7.5 tells us that k = \n] > 7, 
and so we are done. 

Case DCtx_CoVar: By induction. 

Case DTy_Var: By induction. 

Case DTy Con: By induction. Note that relating the result type (well-typed 
in Pico) to the input type (well-typed in Pico=) by = requires congruence, 
Property F.2. Congruence is similarly used in many other cases. 

Case DTy AppRel: 


E; T Ihty t 1 : K 0 Kq = na: Re |Ki. k 2 
E; T Ihty t 2 : k[ = k[ 

E; r Ihty tit 2 : K 2 [r 2 /a] 


DTy_AppRel 


The induction hypothesis tells us E; |T] hty |Yi] : k' q where k' 0 = /c 0 , and 
E; [T] hf y |"r 2 ] : k'[ where k'{ = k\ . By Property F.5, we get = IIfl: Re |/«i. k 2 . 
By Lemma C.43, we have E; Rel(|T]) ht y n' Q : Type. Thus by Property F.7, we 
get S;Rel(rrl)by na: Re |Ki. k 2 : o. Inversion tells us that a = Type. We can 
thus use Property 7.1 and Property F.l to get 71 such that E; Rel( |T~|) ly 0 7 i : 
~ na: R ei«;i. k 2 . 

Now, inversion and Lemma C.7 tells us E; Rel(|T]) by ^1 : Type and Lemma 
C.43 tells us E;Rel(|T]) by k'[ : Type. Thus Property 7.1 and Property F.l 
give us 72 such that E;Rel((T]) bo 72 : ~ K\. We now choose \t\ t 2 ] = 

(rril > 71 ) ( \ t % \ > 72 ) and we can see that E; |T] by \ t \ t 2 ] : k 2 [ f%] > 72 /a] as 
desired. Relating this output kind to the input kind is achieved by Property F.2 
and Property 7.5. 

Case DTy_AppIrrel: Similar to previous case. 
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Case DTy_CApp: Similar to previous cases, but appealing to Lemma F.3. 

Case DTy Pi: 


E; I'. Rel(< 5 ) lb k : r r = Type 
E; T Ihty n< 5 . k : Type 

The induction hypothesis gives us E; (T, Rel(< 5 )"| by |"k] : r' where r' = r. Lemma 
C.43 tells us E; [Rel(r, 8 )] by t' : Type. We know E; [RelfT, 8 )] by Type : Type 
by Lemma C.38 and Lemma C.10. We can thus use Property F.l to get 7 such 
that E; [Rel(r, 5)] bo 7 : t' ~ Type. We can conclude E; (T, Rel(A)] by M > 7 : 
Type. By the extra condition in the induction hypothesis for contexts, we 
can rewrite this to E; Rel(< 5 ') by > 7 : Type, where 8 ' = 8 . We can 
now use Ty_Pi to conclude E; |T] by n<5'. (\k\ > 7 ) : Type as desired. Here, 
[n< 5 . k] = n^'. (\k] > 7 ). 

Case DTy Cast: 


E; Rel(r) lb 0 7 : K\ ~ k 2 

E; T lht y t : k[ E;Rel(r) l^ y k 2 : a 

«i = «i cr = Type 

E; T lb, t > 7 : k 2 

The induction hypothesis gives us: 


DTy_Cast 


• E; Rel((T]) bo l' '■ K '\ ~ K 'i with k'[ = and k" = 

• E; |T] by M : K'T where k"' = 

• E; Rel(|T]) by : cr' where cr' = a 


Lemma C.44, Lemma C.43, Property 7.1, and Property F.l give us 70 such 
that E; Rel (|T]) bo 7 o : *!" ~ K i- We can thus use Ty_Cast to get E; |T] by 
M > 70 : k 2 as desired. 

Case DTy_Case: Along the lines of similar cases. We need Lemma F .8 to establish 
that the result type of the scrutinee does not mention the bound telescope A. 

Other cases: Proceed as above. At this point, we have seen a variety of constructs 
and how to handle them. The remaining cases are similar, using the properties 
of = and = to get from a typing derivation in PlCO= to one in PlCO. 


□ 
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